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Preface 


The Guide to Networking on VAX/VMS presents an introduction to networking 
software used on VAX/VMS systems. It provides a conceptual description of 
DECnet-VAX software used to access the DECnet network, and VAX Packetnet 
System Interface (PSI) software used to access packet switching data networks. 
The guide explains how to configure and manage the network using the 
VAX/VMS Network Control Program (NCP), the primary tool for network 
management. It also explains how to perform user operations over the network. 


Intended Audience 

The Guide to Networking on VAX/VMS is intended for those 
who will be performing network management functions to 
control, monitor, or test DECnet-VAX and VAX PSI software 
running on a VAX/VMS operating system. The guide is also 
intended for VAX/VMS users who will be performing remote 
file access or task-to-task operations using DECnet-VAX. The 
manual assumes the reader is familiar with VAX/VMS, but may 
or may not have experience with DECnet operations. 


Structure of This Document 

The Guide to Networking on VAX/VMS is divided into four 

major parts: 

• Part I, Introduction to DECnet-VAX and VAX PSI, 
introduces the user to basic networking concepts required to 
understand DECnet-VAX operations, and indicates how the 
use can interact with the network. 

• Part II, Network System Management, provides usage 
information to those responsible for DECnet-VAX system 
management. Explains how to use the Network Control 
Program to manage the network and perform VAX/VMS 
host services to remote systems (such as downline loading 
and upline dumping). 

• Part III, Network Configuration, Installation, and Testing, 
specifies the procedures for configuring, installing, and 
testing DECnet-VAX and VAX PSI on a VAX/VMS 
operating system. 
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• Part IV, Network User Operations, describes the techniques 
for carrying out user operations over the network, 
including accessing remote files and performing task-to-task 
communications. 


Associated Documents 

The networking concepts and operations described in the Guide 
to Networking on VAX/VMS are directly related to the following 
two sections of the VAX/VMS Utilities Reference Volume: 

VAX/VMS Network Control Program Reference Manual 

VAX/VMS DECnet Test Sender/DECnet Test Receiver Utility 
Reference Manual 

DECnet-VAX messages are documented in the VAX/VMS 
System Messages and Recovery Procedures Reference Manual. The 
procedure for installing the key for the DECnet-VAX license is 
described in the DECnet-VAX Key Installation Guide. 

The information in the networking guide is also related to these 
other VAX/VMS manuals: 

Introduction to the VAX/VMS Document Set (which provides 
information on the entire VAX/VMS documentation set) 

Guide to VAX/VMS System Management and Daily Operations 

VAX/VMS DCL Dictionary 

VAX/VMS System Routines Reference Volume 

Guide to VAX/VMS File Applications 

See also the VAX/VMS Release Notes. 

The Introduction to DECnet manual, not part of the VAX/VMS 
documentation set, provides an overview of DECnet software. 
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For information concerning VAX PSI, refer to the Introduction 
to VAX PS/, which introduces packet switching data networks, 
the X.25 and X.29 interfaces, and the VAX PSI product. Refer 
to the VAX PSI Installation Procedures to learn how to install 
and test installation of PSI. For information on using VAX PSI 
in your own particular network, refer to the appropriate PSI 
reference card. The PSI user facilities are described in the VAX 
PSI X.25 Programmer's Guide , the VAX PSI X.29 Programmer's 
Guide , VAX PSI Management Utilities Manual , and VAX PSI User 
Utilities Manual. See also the VAX PSI Release Notes. 

The following functional specifications define DIGITAL 
Network Architecture (DNA) protocols to which all 
implementations of DECnet adhere: 

DECnet DIGITAL Network Architecture General Description 

DIGITAL Data Communications Message Protocol Functional 
Specification 

Network Services Protocol Functional Specification 
Maintenance Operation Protocol Functional Specification 
Data Access Protocol Functional Specification 
Routing Layer Functional Specification 
DNA Session Control Functional Specification 
Network Management Functional Specification 
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Conventions Used in This Document 


Convention 

Meaning 

SET LINE line-id COST cost 

Command example verbs 
and keywords are shown in 
a command line in capital 
letters, and they must 
be entered as shown. 
Arguments are shown 
in command lines as 
lowercase letters. (In 
this case, you substitute 
the argument shown in 
the command format with 
the precise information 
requested.) 

OFF ) 

Keywords or arguments 

ON / 

within braces indicate that 

RESTRICTED ( 

you must choose only 

SHUT ) 

one of the keywords or 
arguments. (Do not include 
the braces when entering 
the command.) 

SET KNOWN LINES ALL 

You can abbreviate any 

SE KN LINE ALL 

command verb or keyword 
to its fewest unique letters. 
(In this manual, however, 
we use the complete 
verb and keyword(s) in 
all commands, formats and 
examples.) 


Vertical series of periods, 
or ellipses, mean either that 
not all the data that the 
system would display in 
response to the particular 
command is shown or that 
not all the data a user would 
enter is shown. 
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Convention 

Meaning 

LOAD NODE ... 

Horizontal ellipsis indicates 
that additional parameters, 
values, or information can 
be entered. 

NCP>EXIT 

Command examples show 
all output lines or prompting 
characters that the system 
prints or displays in black 
letters. 

|CTRL/x| 

This document uses red 
lettering to indicate all user- 
entered commands and to 
show general command 
formats. 

The phrase CTRL/x 
indicates that you must 
press the key labeled CTRL 
while you simultaneously 
press another key, for 
example, CTRL/C, CTRL/Y, 
CTRL/O. In examples, this 
control key sequence is 
shown as "x, for example, 

X, *Y, X, because that is 
how the system echoes 
control key sequences. 

<RET> 

A symbol with a one- to 
three-character abbreviation 
indicates that you press 
a key on the terminal, for 
example, <RET> . 

[opt-arg] 

Square brackets indicate 
that the enclosed item is 
optional. 
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New and Changed Features 


The following technical changes have been made to DECnet- 
VAX software as described in the Guide to Networking on 
VAX/VMS for VAX/VMS Version 4.0: 

• Addition of DECnet-VAX Phase IV area routing capability 

• Addition of proxy access login control 

• Addition of support of asynchronous DDCMP lines 

• Addition of support for Micro VMS system 

• Addition of DECnet-VAX capability to connect to the 
console of an unattended remote node 

• Insertion of procedures for configuring a DECnet-VAX node 
as a VAX PSI multihost connector node or as a host node 
that uses the connector node to access a packet switching 
data network 

• Addition of X.25 access module to NCP Utility program to 
permit access to a connector node 

The following technical changes have been made for VAX/VMS 
Version 4.2: 

• Addition of support for dynamic switching of asynchronous 
DDCMP lines 

• Addition of the capability to update the local node 
database(s) by copying remote node information from the 
node database of any accessible node 

The Guide to Networking on VAX/VMS contains information 
previously published in Chapters 1 through 7 and Appendixes 
A through C of the DECnet-VAX System Manager's Guide and in 
the DECnet-VAX User's Guide . 
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PART I: Introduction to DECnet-VAX and 
VAX PSI 










Overview of DECnet—VAX and 
VAX PSI 


This chapter presents an overview of the networking software 
used on VAX/VMS systems: what the software is, how to 
manage it, and how to interface with it as a user. The chapter 
introduces DECnet-VAX software, which enables access to the 
DECnet network, and VAX PSI software, which provides access 
to a packet switching network. The same VAX/VMS network 
management tools are used to manage both DECnet-VAX and 
VAX PSI. 

The following sections introduce the network terms and 
concepts that you will encounter throughout this manual, 
identify network software, describe network configurations, 
and provide a brief summary of network management 
responsibilities. The chapter also defines the application user's 
relationship to the network. 

For details about specific topics, you should consult the 
pertinent chapters of this manual, other manuals in the 
VAX/VMS document set, and VAX PSI manuals (see the 
Preface). 


1.1 General Description of a DECnet Network 

Computer processes communicate with one another over a 
data network. This network consists of two or more computer 
systems called nodes and the logical links between them. A 
logical link is a connection, at the user level, between two 
processes. Adjacent nodes are connected by physical lines 
over which circuits operate. A circuit is a communications data 
path over which all input and output (I/O) between nodes 
takes place. A circuit can support many concurrent logical 
links. 

Nodes can also be physically connected to a packet switching 
data network (PSDN) to allow DECnet circuits to be mapped to 
PSDN virtual circuits. Virtual circuits are logical associations 
between nodes for the exchange of data; the actual circuit 
employed is invisible to the user. Alternatively, computers or 
terminals can be attached directly to a PSDN without using a 
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DECnet data link, or can use a connector node as a gateway to 
communicate with remote nodes over a PSDN. 

In a network of more than two nodes, the process of directing 
a data message from a source to a destination node is called 
routing. DECnet supports adaptive routing, which permits 
messages to be routed through the network over the most 
cost-effective path; messages are rerouted automatically if a 
circuit becomes disabled. 

Nodes can be either routing nodes (called routers) or 
nonrouting nodes (known as end nodes). Both routing nodes 
and end nodes can send messages to and receive messages from 
other nodes in the network. However, routing nodes have the 
ability to forward or route messages from one node to another 
when the two nodes exchanging these messages have no direct 
physical link between them, except for the path that includes 
the node forwarding the message. End nodes can never have 
more than one circuit connecting them with the network. Any 
node that has two or more circuits connecting it to the network 
must be a router. 

Phase IV DECnet supports the configuration of very large, 
as well as small, networks. In a network that is not divided 
into multiple areas, a maximum of 1023 nodes is possible, but 
the optimum number of nodes is much less (approximately 
200 to 300 nodes, depending on the topology). Area routing 
techniques permit configuration of very large networks, 
consisting of up to 63 areas, each containing a maximum of 
1023 nodes. In a multiple-area network, nodes are grouped 
into separate areas, each functioning as a subnetwork. DECnet 
supports routing within each area and a second, higher level 
of routing that links the areas. Nodes that perform routing 
within a single area are referred to as level 1 routers; those 
that perform routing between areas as well as within their own 
area are called level 2 routers (or area routers). 


1.2 DECnet-VAX and VAX PSI 

DECnet-VAX networking software can be configured on all 
VAX/VMS operating systems and all Micro VMS operating 
systems. VAX PSI software can also be installed and configured 
on VAX/VMS systems. These software products are identified 
and described below. 
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1.2.1 DECnet Interface with VAX/VMS 

DECnet is the collective name for the software and hardware 
products that are a means for various DIGITAL operating 
systems to participate in a network. DECnet-VAX is the 
implementation of DECnet that causes a VAX/VMS operating 
system to function as a network node. As the VAX/VMS 
network interface, DECnet-VAX supports both the protocols 
necessary for communicating over the network and the 
functions necessary for configuring, controlling, and monitoring 
the network. A DECnet-VAX node can communicate with 
other DECnet-VAX nodes in the network or with any other 
DIGITAL operating system that supports DECnet. 

A DECnet multinode network is decentralized; that is, many 
nodes connected to the network can communicate with each 
• other without having to go through a central node. As a 

member of a multinode network, your node can communicate 
with any other network node, not merely the nodes that reside 
next to you, and gain access to software facilities that may not 
exist on your local node. An advantage of this type of network 
is that it allows different applications running on separate 
nodes to share the facilities of any other node. 

Optionally, very large DECnet networks can be divided into 
multiple areas, for the purpose of hierarchical (area) routing. 
Area routing introduces a second, higher level of routing 
between areas (groups of nodes), which results in less routing 
traffic throughout the network. Each node in a multiple-area 
network can still communicate with all other nodes in the 
network. 


1.2.2 VAX Packetnet System Interface 

VAX Packetnet System Interface (PSI) is the software product 
that allows the VAX/VMS user to participate in a packet¬ 
switching environment. VAX PSI implements the CCITT 
X.25 and X.29 recommendations (described in Section 1.3.4), 
providing a user interface to a PSDN. A PSDN consists of 
switching nodes connected by high-speed links, to which 
computers or terminals can be attached. 
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You can use VAX PSI to link DECnet nodes across a PSDN 
through data link mapping (DLM), which permits an X.25 
virtual circuit to be used as a DECnet data link. You can also 
attach your computer or packet-mode terminal directly to 
the PSDN and communicate over an X.25 virtual circuit with 
a remote node connected to the PSDN. You can connect a 
character-mode (asynchronous) terminal to a packet assembly 
/disassembly (PAD) facility within the PSDN. 


Another way in which you can communicate with a remote 
node over a PSDN is through an X.25 multihost connector 
node. The connector node is a VAX/VMS system configured 
with VAX PSI software in multihost mode. The node that 
uses the services of the connector node is called a host node. 

A host node is a VAX/VMS system configured with VAX 
Access software. Alternatively, your VAX/VMS node can use a 
server-based X.25 gateway node to communicate over a PSDN, 
provided you have VAX XEP software installed on your node. 


1.2.3 


DECnet Functions 


Networking functions you can perform using DECnet-VAX are 
listed below. These functions are introduced in this chapter and 
described in detail in later chapters of this manual, as indicated. 


• Network management functions 

— Controlling the network (Chapters 2 through 7) 

— Providing DECnet-VAX host services to other DECnet 
nodes (Chapter 4) 

— Performing routing configuration and control (Chapters 2 
and 3) 


— Establishing DECnet-VAX configurations (Chapters 2, 3 
and 5) 


• Applications user functions 

— Accessing files across the network (Chapters 8 and 9) 

— Using a heterogeneous command terminal (Chapter 8) 

— Performing task-to-task communications across the 
network (Chapter 8) 
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DECnet products are based on the layered network design 
specified in the DIGITAL Network Architecture (DNA). 

Figure 1-1 illustrates the DECnet functions, the various DNA 
layers at which they are initiated, and the DNA protocols 
by which these functions are implemented. Each DNA layer 
is a client of the next lower layer and does not function 
independently. For a complete description of DNA, see the 
DNA specifications. The DECnet-VAX configurations that use 
the Ethernet, DDCMP, Cl, and X.25 protocols are defined in the 
following section. 

Figure 1-1 DECnet Functions and Related DNA Layers and 
Protocols 
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1.3 DECnet-VAX Configurations 

DECnet supports the following network connections: 

• A connection to an Ethernet circuit in a local area network 
configuration 
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1.3.1 


• A connection to a node running DECnet using the DIGITAL 
Data Communications Message Protocol (DDCMP): either a 
synchronous point-to-point or multipoint connection or an 
asynchronous static or dynamic point-to-point connection 

• A connection over the computer interconnect (Cl) to another 
node running DECnet 

• An X.25 connection to a node running DECnet (either a 
direct connection over a PSDN or a connection made by 
means of an X.25 multihost connector node that accesses a 
PSDN) 


Figure 1-2 is a sample DECnet-VAX Phase IV configuration 
that illustrates various kinds of DECnet-VAX nodes (MicroVMS 
end nodes, VAX/VMS routers, and VAX/VMS end nodes in 
a VAXcluster) connected to an Ethernet, and two Ethernets 
connected by means of routers. The figure shows the use of 
a DDCMP synchronous line to connect a router to additional 
DECnet nodes, and static (permanent) asynchronous DDCMP 
lines to connect Micro VMS end nodes to a router. It also 
indicates a dialup connection between a Micro VMS system and 
a routing node in the VAXcluster over a dynamic asynchronous 
DDCMP line (switched on for the length of the call). 

The figure demonstrates two kinds of connections to a PSDN: a 
VAX/VMS node connected directly to a PSDN by means of an 
X.25 circuit, and VAX/VMS host nodes connected to a PSDN 
by means of a VAX/VMS connector node that serves as a 
gateway to the PSDN. DECnet-VAX connections are described 
below. A detailed discussion of the various types of circuits and 
lines used in a DECnet network is presented in Chapter 2. 


DECnet—VAX Ethernet Local Area Network 
Configuration 

The Ethernet is a local area network component that provides 
a reliable high-speed communications channel, optimized 
to connect information processing equipment in a limited 
geographic area, such as an office, a building, or a complex of 
buildings (for example, a campus). 
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Figure 1-2 Sample DECnet-VAX Phase IV Configuration 
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1.3.1.1 


Local area networks (LANs) are designed for a wide variety 
of technologies and arranged in many configurations. 

Digital Equipment Corporation, Intel Corporation, and 
Xerox Corporation collaborated in producing the Ethernet 
specification to develop a variety of LAN products. DIGITAL's 
implementation of the Ethernet specification that was originated 
by the Xerox Corporation appears at the lowest two levels of 
the overall DNA specification: the Physical layer and the Data 
Link layer. 

At the Physical layer, the Ethernet topology is a bus, in the 
shape of a branching tree, and the medium is a shielded 
coaxial cable that uses Manchester-encoded, digital baseband 
signaling. The maximum data rate is 10 million bits per 
second. Maximum utilization of an Ethernet's data transmission 
capability occurs when multiple pairs of nodes communicate 
simultaneously. In practice, DECnet transmission between 
a pair of nodes on an Ethernet occurs at a considerably 
lower rate. Each Ethernet can support up to 1023 nodes; the 
maximum possible distance between nodes on the Ethernet is 
2.8 kilometers (1.74 miles). 

At the Data Link layer, network control for the Ethernet is 
multiaccess, fairly distributed to all nodes. Ethernet access 
control is CSMA/CD. The frame length allocation is from 64 to 
1518 bytes (including an 18-byte envelope). 

Ethernet circuit devices supported by DECnet-VAX are the 
DEUNA (known as the UNA) and the DEQNA (called the 
QNA). The VAX/VMS system uses the DEUNA, and the 
Micro VMS system uses the DEQNA. 


Ethernet Datagrams 

Message packets sent over Ethernet are called datagrams. 
Because there is no guarantee that a datagram will be received 
by the intended destination(s), reliable connections (in the form 
of virtual circuits) may be provided by interposing a protocol 
between the user and the Ethernet datagram service. In DNA, 
this virtual circuit is provided by the Network Services Protocol 
(NSP) in the End Communication layer. 

Initialization of nodes on Ethernet is based on multicast 
addressing and the use of datagrams. It differs from 
initialization of nodes on DDCMP circuits in that it does 
not involve guaranteed delivery of routing messages. 
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1.3.1.2 Transmission and Reception of Ethernet Packets 

An Ethernet is a single shared network channel, with many 
nodes demanding equal access to it. The technique used to 
mediate these demands is CSMA/CD (Carrier Sense, Multiple 
Access with Collision Detect). A good analogy for this 
technique is the interaction of people at a social gathering. To 
be polite, one does not speak while someone else is talking, 
that is, one listens before speaking; on the Ethernet, listening 
to determine whether the communication medium is already in 
use is called carrier sense. Messages are said to be initially 
deferred if they are not sent on the Ethernet because a 
transmission is in progress. 

At a social gathering, anyone may begin to talk once he or she 
determines that no one else is; the ability of any station on 
the Ethernet to use the communication medium is known as 
multiaccess. If two or more people, detecting silence, start to 
talk at about the same time, they note the fact and stop talking 
(that is, each listens while talking and stops if interfering with 
someone else); the noting of the fact that more than one station 
is transmitting, followed by the cessation of communication, is 
called collision detect. 

When two or more people at a social event start talking 
simultaneously, they stop talking, wait some random time, and 
start talking again; on an Ethernet, this situation is known as 
backoff and retransmission, and it is expected that a random 
delay before retransmission will eventually clear the collision 
situation. 

There is a further useful analogy between Ethernet and a social 
event. When one is talking to a group of people, everyone 
can hear everything said. Some of what is said is intended 
for everyone, some is intended for a subset of the group (say, 
everyone over 21), and some is intended for an individual. 
Stations on an Ethernet can hear every message. Some 
messages are intended for all stations (broadcast address), 
some are intended for a subset (multicast address), and some 
are intended for individual stations (physical address). 

On an Ethernet, every station can listen to every message, and 
messages can be addressed to their intended recipient(s). These 
two features greatly increase the communications efficiency of a 
network that uses Ethernet over that of a completely connected 
DDCMP network. 


1-9 




Overview of DECnet-VAX and VAX PSI 


1.3.1.3 Ethernet Routers and End Nodes 

Ethernet supports connections to routers and end nodes. On 
an Ethernet, a routing node selected as a designated router 
can perform routing services on behalf of end nodes. In 
addition, routers can route packets between Ethernet nodes 
and non-Ethernet nodes (such as nodes on DDCMP circuits). 
An end node on an Ethernet can communicate directly with 
any other node (router or end node) on the same Ethernet by 
sending a message directly to the addressed node. Note that an 
end node on a non-Ethernet circuit can only communicate with 
an adjacent node on the same circuit. 


1.3.2 DDCMP Network Configurations 

DDCMP provides a low-level communications path 
between systems. The DDCMP protocol performs the 
basic communications function of moving information blocks 
over an unreliable communication channel. (The protocol 
detects any bit errors introduced by the channel and requests 
retransmission of the block.) DDCMP is also used to manage 
the orderly transmission and reception of blocks on channels 
with one or more transmitters and receivers. 

The DDCMP protocol is supported on synchronous and 
asynchronous communications devices. DDCMP connections 
can be point-to-point or multipoint configurations. Point-to- 
point connections are either synchronous or asynchronous. The 
two types of asynchronous connections are static (permanent) 
and dynamic (switched temporary). Multipoint connections are 
always synchronous. These connections are described below. 


1.3.2.1 DDCMP Point-to-Point and Multipoint Connections 

Figure 1-3 illustrates DDCMP point-to-point and multipoint 
configurations. A point-to-point configuration consists of two 
systems connected by a single communication channel. 

A multipoint configuration consists of two or more systems 
connected by a communications channel, with one of the 
systems (called the control station) controlling the channel. 
All other systems on the communications channel are known 
as tributaries. (Note that if only two systems are connected 
in a multipoint configuration, one is the master and one is 
the tributary. However, this is not a very efficient use of the 
communication channel.) The control station is responsible 
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for telling the tributaries, in turn, when they may use the 
channel; this procedure is known as polling. Tributaries are 
not allowed to use the channel until they are polled. The 
control station, however, may use the channel whenever it 
is available. Also, the tributaries on a multipoint line are not 
allowed to communicate directly with each other, but only 
through the master. 

Figure 1-3 Typical DDCMP Point-to-Point and Multipoint 
Connections 
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Point-to-point circuits and multipoint circuits perform as virtual 
circuits: nodes on these circuits interact as though a specific 
circuit were dedicated to them throughout the transmission; 
in fact, however, the actual physical connection is allocated 
by the routing mechanism. Initialization of nodes on DDCMP 
circuits involves guaranteed delivery of routing messages. 

Also, individual nodes on DDCMP circuits must be addressed 
directly; no multicast or broadcast addressing capability is 
available as with an Ethernet circuit. 
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I 1.3.2.2 


1.3.2.3 


Synchronous DDCMP Connections 

Synchronous communications devices are used for high speed 
point-to-point or multipoint communication (for example, 
connecting two VAX-11/780 systems). 


The synchronous DDCMP protocol can run in full or half 
duplex operation. This allows DDCMP the flexibility of being 
used for local synchronous communications, or for remote 
synchronous communications over a telephone line using 
a modem. DDCMP has been implemented in microcode in 
such devices as the DMC11 and DMR11 to run at speeds up 
to one megabit per second in a point-to-point configuration. 
The DDCMP multipoint protocol (point-to-point also) has 
been implemented in microcode in the DMP11 device to run 
at speeds up to 500 kilobits per second. For the DMF32, 
DDCMP has been implemented in the driver software for the 
synchronous communications port. 


Asynchronous DDCMP Connections 

Asynchronous connections provide for low speed, low cost, 
point-to-point communication (for example, as an inexpensive 
way of connecting a MicroVAX system to a VAX-11/780 
system). Asynchronous DDCMP is implemented in software 
and can be run over any terminal line that VAX/VMS supports. 

Two kinds of asynchronous connections can be made over the 
network: 

• A static connection: the asynchronous line is permanently 
configured as a communications device 

• A dynamic connection: a line connected to a terminal port 
is switched to an asynchronous communications line for the 
duration of a telephone call 
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1.3.2.4 Static Asynchronous Connections 

A static asynchronous DDCMP connection is a permanent 
DECnet connection between two nodes (for example, a 
Micro VMS node and a VAX/VMS node) physically connected 
by terminal lines. The terminal lines are converted to static 
asynchronous DDCMP lines by issuing commands to set the 
lines to support the DDCMP protocol. The user at each node 
then turns the appropriate circuits and lines on for DECnet 
use. Once the communications link is established, it remains 
available until a user turns off the circuit and line and clears the 
entries from the DECnet database. 

Static asynchronous DDCMP configurations require that the 
asynchronous DDCMP driver be connected. The asynchronous 
DDCMP protocol can run in full duplex operation on 
local asynchronous communication devices. Examples of 
these devices are the DZ11 and the DMF32 asynchronous 
communications port. 

The user can configure a dialup line as either a static or 
dynamic asynchronous line, but may find the dynamic 
connection more secure and convenient to use. 


1.3.2.5 Dynamic Asynchronous Connections 

A dynamic asynchronous connection is a temporary connection 
between two nodes, generally over a telephone line using 
modems. The terminal lines at each end of the connection can 
be switched to asynchronous DDCMP communications lines 
for the duration of the call and then switched back to terminal 
lines. 

You can use dynamic asynchronous connections to establish a 
DECnet link to another computer for a limited time or to create 
links to different computers at different times. 

For example, as a Micro VMS system user, you can cause a 
dynamic asynchronous connection to be made for the length 
of the telephone call to a VAX-11/780 system. You must first 
establish your system as a terminal emulator (enabling the 
processor to perform as though it were a terminal line). You 
dial in over a telephone line to the other system (which is 
established as a virtual terminal) and log in. You can then 
issue a command which causes the terminal lines at each end 
of the connection to be switched to asynchronous lines for 
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1.3.3 


DECnet use. When you hang up, the lines are automatically 
switched back to terminal lines. 

Security measures provide protection against a caller at an 
unauthorized node being able to form a dynamic asynchronous 
connection with another node (see Section 2.10.6). Before 
a dialup node can establish a dynamic connection with a 
remote node, the remote node verifies that the dialup node 
is authorized to make a connection. It checks that the node 
is of the appropriate type (router or end node), and, without 
revealing its own password, verifies the routing initialization 
password sent by the dialup node. Also, for increased security, 
the connection will be ended automatically when the telephone 
is hung up. 

A dynamic asynchronous connection can also be established 
over a hardwired terminal line. The connection is maintained 
for the duration of the DECnet session. The dynamic 
connection permits the system to be used as a terminal 
emulator when not switched to DECnet use. 


DECnet-VAX Configurations for VAXclusters 

A VAXcluster is an organization of VAX/VMS systems that 
communicate over a high-speed communications path, the 
Cl, and share processor resources as well as disk storage. 

Figure 1-4 shows a typical VAXcluster. The Cl is the physical 
link between the nodes in a VAXcluster. Cl cables from the 
individual nodes in the cluster are connected to a star coupler. 
The HSCs are hierarchical storage controllers that enable 
VAXcluster nodes to share disks. 

DECnet-VAX connections are required for all VAX/VMS 
systems in the VAXcluster. Use of DECnet-VAX ensures 
that VAXcluster system managers can access each node in 
the cluster from a single terminal, even if terminal-switching 
facilities are not available. DECnet-VAX is also required by the 
UETP. 

The choices for DECnet-VAX physical links for use in the 
VAXcluster are 

• Connecting each VAX/VMS node in the cluster to an 
Ethernet (as shown in Figure 1-2) 
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Figure 1-4 Typical VAXcluster Configuration Using Cl as a Data 
Link 
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• Using the Cl that connects the cluster nodes as the 
DECnet-VAX data link (as shown in Figure 1-4) 

Connecting each VAXcluster node to an Ethernet provides 

distinct advantages: 

• Each node in the cluster can be an end node, resulting in 
lower overhead for these nodes, decreased routing traffic 
throughout the network, and simpler installation procedures. 
Note that there must be at least one router on the Ethernet 
to which the cluster end nodes are attached. 

• Ethernet provides for better performance in DECnet 
transmissions than the Cl, despite the higher data link 
bandwidth of the Cl, because the Ethernet communications 
protocol allows larger buffer sizes. 
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• Terminal servers can be used when nodes in a VAXcluster 
are connected to an Ethernet. DIGITAL's terminal servers 
offer a number of benefits to the VAXcluster user, such as 
load balancing and easier cluster management. 


If only one physical link is used to connect each cluster node 
to the network, the Ethernet link should be used instead of the 
Cl data link, because of the better DECnet performance of the 
Ethernet. In this case, the Cl should perform the functions of a 
system bus and not be enabled as a DECnet data link. 

A VAXcluster node connected to an Ethernet may require 
additional DECnet links in order to communicate with remote 
nodes not on the Ethernet, or to communicate with a Micro VMS 
system over an asynchronous DDCMP line. A VAXcluster node 
connected to more than one DECnet link must be configured as 
a router, not an end node. 

If the nodes in the VAXcluster are not connected to an Ethernet, 
the Cl should be used as the DECnet data link between the 
nodes. Cl circuit devices are treated as though they were 
multipoint devices, but each node on the Cl can talk directly to 
every other node and no polling is involved. 

A two-node VAXcluster that uses the Cl as the data link can 
be configured using end nodes. The end node in a VAXcluster 
that uses a Cl data link will always send messages to the 
nearest router. If additional nodes are configured in the cluster, 
however, at least one router is required. The Cl does not 
have a broadcast capability (such as that of the Ethernet). 

Thus, the router is needed so that the nodes in the cluster 
can identify each other. If the router in a three-node cluster 
fails, the cluster reverts to being a two-node cluster, which can 
consist of end nodes only. You can use NCP to create a circuit 
between the end nodes. For a cluster of four or more nodes, 
more than one router is required in order to prevent the loss of 
communications capability between the remaining nodes if one 
router fails. Also, you could provide backup circuits between 
end nodes in case of router failure. 
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1.3.4 X.25 Network Configurations 

Packet switching data networks provide fast, dependable 
communications between geographically distributed nodes. 
Data transmitted over a PSDN is divided into packets, each 
of which has a header containing control and destination 
information. The PSDN interleaves packets from many users 
over shared transmission lines and delivers the packets in the 
correct order to the proper destinations. The routing of packets 
through the PSDN is handled by the PSDN and is invisible to 
the user. 

A PSDN consists of switching nodes (network interfaces), 
connected by very-high-speed links, to which you attach your 
computer or terminal. Your computer or terminal is called 
data terminal equipment (DTE) and the network interface to 
which it is connected is known as data circuit-terminating 
equipment (DCE). The DTE can operate in packet mode or in 
character mode (for example, an asynchronous terminal). A 
character-mode terminal is also known as an X.29 terminal. 


1.3.4.1 X.25 and X.29 Recommendations 

Recommendations for standard network interfaces for DTEs 
have been established by the CCITT (Comite Consultatif 
International Telegraphique et Telephonique). The X.25 
recommendation defines the interface between the packet-mode 
DTE and the DCE. The X.25 recommendation defines three 
levels of protocol for this interface: Level 1 covers physical and 
electrical characteristics; Level 2, link access procedures; and 
Level 3, packet procedures. 

The X.29 recommendation defines the procedures for 
information exchange between a character-mode DTE (an 
asynchronous terminal) and the packet assembly/disassembly 
(PAD) facility of the PSDN. 

Communication between the local DTE and a remote DTE is 
by means of a X.25 virtual circuit, a logical association between 
the two DTEs set up specifically to handle the exchange of 
data between them. An X.25 virtual circuit can be permanent 
or temporary. The permanent virtual circuit (PVC) is similar 
to a leased line. The temporary or switched virtual circuit 
(SVC) is similar to a dialup line and requires that calls be set 
up and cleared. The local DTE is connected to the PSDN by a 
synchronous X.25 line, over which X.25 virtual circuits operate. 
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Examples of X.25 lines are the DUP11 and the DMF-32 
synchronous line unit. 


1.3.4.2 X.25 Connections 

Figure 1-5 illustrates typical X.25 connections that permit a 
VAX/VMS node to communicate with a remote node over a 
PSDN. A VAX/VMS node can be configured to communicate 
over a PSDN in the following ways: 

• By means of a data link mapping (DLM) circuit, an X.25 
virtual circuit used as a DECnet data link (provided the 
remote node runs PSI and DECnet-VAX or DECnet-RSX) 

• Through a direct connection to a PSDN over an X.25 
virtual circuit (this mode of operation is called native-mode 
operation) 

• As a host node using a VAX/VMS multihost connector node 
to access a PSDN 

You must have VAX PSI software installed on your DECnet- 
VAX node to configure your node for VAX PSI native-mode 
operation or multihost-mode operation. Native-mode operation 
permits incoming and outgoing calls to be made between the 
local node and a remote DTE. Multihost-mode operation allows 
the local node to be a connector node or gateway, which host 
nodes can use to communicate over a PSDN with remote DTEs. 
Each host node must have VAX PSI Access software installed. 

Alternatively, a VAX/VMS node with VAX XEP software 
installed can access a PSDN by means of an Ethernet 
communications server, the DECnet Router/X.25 Gateway. 


1.4 Managing the Network 

As system manager of a VAX/VMS operating system, you can 
use a network management utility program to configure the 
system as a DECnet-VAX node in the network, and perform 
network management and maintenance functions for your own 
node and other nodes in the network. This section summarizes 
network management functions. 
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Figure 1-5 X.25 Connections in a DECnet Network Configuration 
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1.4.1 Network Control Program 

To configure, control, monitor, and test the network, use the 
Network Control Program (NCP), a VAX/VMS utility program. 
The types of users who employ NCP are 

• Users of both DECnet-VAX and VAX PSI. These users can 
employ all NCP commands. 


1-19 



















Overview of DECnet-VAX and VAX PSI 


1 . 4.2 


• Users of DECnet-VAX only. DECnet-VAX users employ all 
NCP commands except those that relate to X.25 modules. 

• Users of VAX PSI only. PSI native-mode and multi-host- 
mode users (who are not using DECnet-VAX circuits) 
employ only NCP commands that relate to X.25 modules, 
circuits, lines, objects, and logging. 


The network components the system manager configures are 
listed in Section 1.4.5.3 and described in detail in Chapter 2. 
The use of NCP commands and parameters to perform network 
management is discussed in Chapter 3. The NCP commands 
and parameters and guidelines for using them, including 
restrictions on the use of individual NCP parameters, are 
specified in the NCP section in the VAX/VMS Utilities Reference 
Volume. 


Network Management Responsibilities 

As system manager of a DECnet-VAX network, you have a 

number of key responsibilities, which include: 

• Defining network components and their parameters in 
a central configuration database at the local node and, 
optionally, at remote nodes. (The local node is the node 
at which you are physically located; a remote node is any 
node other than the local node in your network.) 

• Coordinating with the system managers of other nodes in 
the network to ensure uniform assumptions about network 
parameter settings such as circuit cost. 

• Configuring your node to ensure proper network routing 
operation and updating VAX/VMS SYSGEN procedures to 
allow enough space for the networking software. 

• Controlling and monitoring local and remote network 
operation. 

• Testing network hardware and software operation. 

• Loading systems downline to unattended remote nodes. 

• Connecting to an unattended remote node to serve as its 
console. 
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If your network includes VAX PSI, you have the following 
additional responsibilities: 

• Defining VAX PSI components and their parameters in the 
network configuration database and thus configuring VAX 
PSI. 

• Monitoring the operation of VAX PSI using PSI management 
utilities. 

• Analyzing hardware and software operation and diagnosing 
problems related to PSI operation. 

The following sections outline the network-related tasks that 
you perform as system manager and describes several of the 
facilities DECnet-VAX and VAX PSI provide to perform those 
tasks. 



1 . 4.3 



DECnet—VAX Licenses 

Licenses are available for either a DECnet-VAX full function 
kit or a DECnet-VAX end node kit. If you have purchased 
either license, you must install the key for the license to enable 
inter-node communication. The procedure for installing the 
appropriate license key is described in the DECnet-VAX Key 
Installation Guide, distributed with the key. 

If you have purchased a license for a DECnet-VAX end node 
kit and now require the additional capabilities of the DECnet- 
VAX full function license, you can purchase a DECnet-VAX 
license that upgrades the end node license to a full function 
license. This upgrading license is applicable to all DECnet-VAX 
nodes. The full function kit contains the material to implement 
this upgrade. 

The DECnet-VAX full function kit allows the node on which 
it has been installed to be configured as either a routing node 
or an end node. The end node kit allows the node to be 
configured only as an end node. 
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Figure 1-6 DECnet-VAX and VAX PSI Software 
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1 . 4.4 DECNET-VAX and VAX PSI Network Management 

Software 

Figure 1-6 displays the DECnet-VAX and VAX PSI software 
that the system manager uses to configure, control, and monitor 
the network. 

Network management software components are described 
below. 

• Ethernet configurator (NICONFIG). NICONFIG is a network 
image that listens to system identification messages on 
Ethernet circuits, and maintains a user-accessible database of 
configuration information on all systems on the Ethernet. 

• Event logger (EVL). EVL is an image that logs significant 
events to provide information to the system manager for 
possible intervention or future reference. 

• File access listener (FAL). FAL is a network image that 
receives and processes remote file access requests for files at 
its node on behalf of remote users. 


1-22 


































Overview of DECnet-VAX and VAX PSI 


• Host loader (HLD). HLD is an image that communicates 
with the DECnet-RSX Satellite Loader (SLD) to load tasks 
downline to an RSX-11S node. 

• Loopback mirror (MIRROR). MIRROR is a network image 
that participates in Network Service Protocol (NSP) and 
Routing layer loopback testing. 

• Network ancillary control process (NETACP). NETACP 
is a VAX/VMS ancillary control process that controls 
all lines and circuits, maintains a picture of the network 
topology, and creates a process to receive inbound logical 
link connection requests. 

• Network Control Program (NCP). NCP is an interactive 
utility program that permits you to control and monitor the 
network. 

• Network driver (NETDRIVER). NETDRIVER is a VAX/VMS 
pseudo device driver that provides logical link and routing 
services. It implements NSP and Routing, and provides a 
user process with a Queue I/O (QIO) interface to a logical 
link service. 

• Network management listener (NML). NML is an image 
that receives network management commands, such as NCP 
commands, from the Network Management layer through 
the Network Information and Control Exchange (NICE) 
protocol. NML performs all local network management 
functions as well as control and information functions 
requested by remote nodes. NML spawns a subprocess, the 
maintenance operation module (MOM), for maintenance 
functions such as downline load, upline dump, and loopback 
testing. 

• PSI ancillary control process (PSIACP). PSIACP is a 
VAX/VMS ancillary control process that controls all X.25- 
related functions. It is present only if VAX PSI is started. 
PSIACP has the VAX PSI volatile database. 

• Permanent database. The permanent database is a collection 
of disk-resident files that define the network as known to 
the local node. If VAX PSI is configured in the network, a 
subset of the permanent database is maintained as the VAX 
PSI permanent database for the local DTE(s). 
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• Volatile database. The volatile database, maintained 
by NETACP, is a memory-resident database containing 
current network configuration parameters. If VAX PSI is 
configured in the network, a subset of the volatile database 
is maintained as the PSI volatile database in PSIACP for the 
local DTE(s). 

Many of these software components are user-transparent 
processes over which the system manager has no control. This 
manual describes DECnet-VAX and VAX PSI software only as 
it serves to highlight and clarify the functions and operation 
of NCP. The various DNA specifications describe the different 
protocols that facilitate network communication. 


1.4.5 Configuring a Network 

The system manager must configure each DECnet-VAX node 
and VAX PSI DTE as part of the network. 


1.4.5.1 Configuring a DECnet—VAX Node 

At the outset, the system manager is responsible for configuring 
the network from the perspective of local node network 
operation. This involves supplying information at the local 
node about various network components such as nodes, 
circuits, lines, and objects. This information constitutes what is 
called the configuration database for the local node. Each node 
in the network has such a database. You supply information 
about the configuration database through NCP. 

If you are configuring a DECnet-VAX node for the first time 
or wish to rebuild the configuration database for your local 
node, you can use the interactive NETCONFIG.COM procedure 
to configure your node automatically. To update an existing 
node database to contain current information about other nodes 
in the network, you can copy the information from the node 
database of another node to which you have access. 

Chapter 3 discusses the function of the configuration database 
and the general use of NCP and most NCP commands. 
Chapter 5 describes the use of the NETCONFIG.COM 
procedure to configure your node automatically, and presents 
sample configuration commands for different typical network 
configurations. The NCP section of the VAX/VMS Utilities 
Reference Volume contains a summary description of NCP 
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operation, command prompting, and the syntax of all NCP 
commands. 


1.4.5.2 Configuring VAX PSI DTEs 

If VAX PSI is to be run, the system manager is responsible 
for installing and configuring VAX PSI for the local DTEs. 
Configuring VAX PSI involves supplying information about 
various VAX PSI components, such as circuits, lines, modules, 
and objects. The information is contained in the DECnet-VAX 
configuration database for the local node and, if both DECnet- 
VAX and VAX PSI are configured, in the PSI configuration 
database for the local DTEs. You use NCP commands to supply 
information to the configuration database. 

If your node is to serve as an X.25 multihost connector node 
to provide access to PSDNs for host nodes, you must configure 
VAX PSI software in multihost mode. If your node is to be 
a host node that uses the multihost connector node to access 
a PSDN, you need to install and configure only the VAX PSI 
Access software. The procedures for configuring VAX PSI 
software or VAX PSI Access software on your DECnet-VAX 
node are described in Chapter 5 . 


1.4.5.3 A Network Topology 

Figure 1-7 illustrates a hypothetical network topology made up 
of various DIGITAL operating systems. Figure 1-8 illustrates 
the same topology for a network that has been divided into 
multiple areas. These examples are referred to as the "network 
examples" throughout this manual. 

Figures 1-7 and 1-8 show some, but not all, of the network 
components about which the system manager gathers and 
consolidates information in the configuration database. The 
six network components that you can control using NCP are 
described below. 

• Nodes. Nodes are DIGITAL operating systems using 
DECnet software to communicate with other operating 
systems across the network. 
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Figure 1-7 Topology of a Single-Area DECnet Network 
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Figure 1-8 Topology of a Multiple-Area DECnet Network 
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• Modules. VAX PSI modules include the X.25 protocol 
module, which performs data packet handling and 
multiplexing of X.25 circuits over the line to the PDSN; the 
X.25 and X.29 server modules, which handle X.25 and X.29 
calls, respectively; and the X.25 trace module, which enables 
tracing of X.25 activity. DECnet-VAX modules include the 
X.25 access module, which permits a VAX/VMS host node 
to communicate over a PSDN by means of a connector 
node, and the Ethernet configurator module, which lists all 
nodes on the Ethernet. 

• Circuits. Circuits are virtual communications paths between 
nodes and between DTEs. Circuits operate over physical 
lines and are the medium on which all I/O occurs. DECnet 
processes "talk" over circuits by means of logical links. 
These links carry a single stream of full-duplex traffic 
between two user-level processes. There can be multiple 
logical links on each DECnet circuit. 

• Lines. Lines are physical data paths between nodes, or 
between DTEs and DCEs (X.25 network interfaces). 

• Objects. Objects are processes that receive logical link 
requests. They perform specific network functions. An 
example is FAL, which is used for remote file access. 
Objects also receive incoming X.25 calls. 

• Logging. Logging is a network feature that enables the 
automatic recording of useful network events that occur 
during network operation. 

These components, the DECnet and PSI software modules 
and databases, and the hardware make up the network. NCP 
command examples in this manual relate to the components 
illustrated in the network example. 


1.5 User Interface to the Network 

This section describes the user interface to the DECnet-VAX 
network. It includes a general description of operations 
that you can perform over the network and a list of the 
programming languages that you can use for designing network 
applications. This section also presents general information that 
you need to know to access the DECnet-VAX network. 
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1.5.1 Performing Network Operations 

You can use the DECnet-VAX software to perform a variety of 
operations over the network. For example, you can 

• Manipulate files on remote nodes (for example, transfer, 
delete, or rename files) 

• Access remote files at the record level 

• Perform task-to-task communications 


DECnet-VAX allows you to access files on remote nodes as 
though they were on your local node. It also allows you to 
design applications that communicate with each other over the 
network. For detailed information on remote file access and 
task-to-task communication, including examples of each type of 
network application, see Chapter 8. 

Throughout this document, the term task refers to an image 
running in the context of a process, the term local refers to the 
node at which you are located physically, and the term remote 
refers to that node with which you establish a connection. Note 
that in certain situations such as testing, a logical link can be 
established between two processes on the same node. 

The VAX/VMS operating system and DECnet-VAX 
communications software are integrated to provide a high 
degree of transparency for user operations. For some 
applications, however, it is desirable (and sometimes necessary) 
to have more direct access to network-specific information 
and operations. For this purpose, DECnet-VAX provides 
nontransparent communication. 

The following sections describe some of the general transparent 
and nontransparent features of DECnet-VAX in terms of the 
user interface to the network. For more detailed information, 
including examples of transparent and nontransparent 
DECnet-VAX applications, see Chapter 8. 

In addition to remote file access and task-to-task 
communication, DECnet-VAX also allows you to communicate 
with remote nodes through the heterogeneous command 
terminal facility (SET HOST). This feature is described in 
Chapter 8. 
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When designing user applications to perform network 
operations, you can use standard DCL commands, higher-level 
language I/O statements, VAX-11 RMS service calls, and 
system service calls. 


1.5.1.1 Designing User Applications for Network Operations 

DECnet-VAX supports several programming languages for 
network applications: 

• DCL commands and command procedures 

• Higher-level language programs 

• MACRO programs using RMS service calls or system service 
calls 


You can use the following higher-level languages to develop 
networking applications: VAX FORTRAN, VAX BASIC, VAX 
BLISS, VAX PASCAL, VAX C, VAX PL/I, and VAX COBOL. 
With any of these languages, you can access remote files and 
create tasks that exchange information across the network. 

Table 1-1 summarizes the normal use of the programming 
languages for specific network operations that you can perform 
with DECnet-VAX. 


Table 1-1 Network Access Levels 


User Language Network Operation 


DCL 


Network command 
terminals 


Remote file 
manipulation 

Task-to-task 

communication 

Higher-level Remote file access 

languages (files and records) 


Language Calls Access 

Level 

DCL commands Transparent 

network 
access 
using DCL 


Higher-level 

language 

I/O statements 
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Table 1-1 (Cont.) Network Access Levels 


User Language 

Network Operation 

Language Calls 

Access 

Level 

MACRO or 
higher-level 
languages 

Task-to-task 

communication 

Remote file access 
(files and records) 

Task-to-task 

communication 

RMS service 
calls 

Transparent 

network 

access 
using RMS 

MACRO or 

Task-to-task 

System service 

Transparent 

higher-level 

languages 

communication 

calls 

and 

nontransparent 
network 
access using 
QIO 


1.5.1.2 Choosing a Language for a Specific Network Application 

The way you access the network is directly related to the 
language you use and the network operation you perform. For 
example, you may want to use standard VAX RMS calls in a 
VAX MACRO program to access remote files, then use system 
service calls to communicate between MACRO programs in a 
task-to-task communication application. Figure 1-9 shows three 
access levels and the corresponding network operations. The 
various levels of network access provide a convenient context 
in which to discuss typical user operations over the network. 

The first two levels of access, DCL and RMS, are entirely 
transparent to the network user. Because you use standard 
DCL commands and RMS service calls to access remote files, 
no DECnet-specific calls are required at these levels of access. 
You need only specify in your file specification the remote node 
on which the file resides. Likewise, higher-level language tasks 
can use a variation of the standard VAX/VMS file specification 
in conjunction with standard I/O statements to access remote 
tasks and exchange information; thus, this form of task-to-task 
communication is also transparent. As with device-independent 
input/output (I/O) operations, transparent network access 
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Figure 1-9 Network Access Levels and DECnet-VAX User 
Interface 
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1.5.2 


allows you to move data across the network with little concern 
for the way this operation is performed. 

The third level of access, system services, provides both a 
transparent and a nontransparent user interface to the network. 
Transparent communication at the system-service level provides 
all the basic functions necessary for two tasks to exchange 
messages over the network. As with the higher-level language 
I/O interface, these operations are transparent because they do 
not require DECnet-specific calls. Rather, you use standard 
system service calls to implement them. Nontransparent 
communication extends this basic set of functions to allow 
a nontransparent task to receive multiple inbound connections 
and to use additional network protocol features such as 
optional user data and interrupt messages. As with device¬ 
dependent I/O, nontransparent communication allows you to 
exploit certain network-specific characteristics to coordinate a 
more controlled communication environment for exchanging 
information. 


Accessing the Network 

This section presents general information that you need to 
know to access the network via DECnet-VAX software. This 
information covers network file and task specifications, access 
control parameters, and the use of logical names in network 
applications. 

The format for file specifications is applicable to file-handling 
operations for both the DCL and the RMS interfaces to the 
network. The task specification format pertains to task-to-task 
communication. The information on access control is significant 
because it defines the way that both local and remote nodes 
grant access to their system resources. 
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1.5.2.1 


Using File and Task Specifications in Network 
Applications 

DECnet-VAX uses the standard VAX/VMS file specification 
format for remote file-handling applications. A node 
specification string that includes a node name must be present. 
You can also include an optional access control string in the 
node specification to specify explicitly the user name and 
password of a specific account to use on the remote system. 

For example, the file specification 

TRNTO"SMITH JOHN"::WORK_DISK:TEST.DAT;1 

contains explicit access control information and can be used 
to access the file TEST.DAT, which resides in user Smith's top 
level directory on the device WORK_DISK on node TRNTO. 

The following file specification, which does not contain explicit 
access control information, can also be used to access the 
remote file TEST.DAT provided that a proxy or default DECnet 
account exists on the target node: 

TRNTO::DBA1:[SMITH]TEST.DAT;1 

For more information on file specification strings, including 
format examples, see the VAX/VMS DCL Dictionary. 

Task-to-task communication requires the use of a task 
specification string enclosed in quotation marks. This string 
identifies the target task to which you want to connect on a 
remote node. For example, the following task specification 
string 

BOSTON::"TASK=TEST2" 

identifies the task TEST2 by means of the TASK= form of task 
specification. You can also use the 0= form to specify a task. 
For example, 

BOSTON"JONES KC"::"0=TEST2" 

also identifies the task TEST2. Note that in this case, explicit 
access control information is also included in the node 
specification string. For more information on task specifications, 
see Chapter 8 . 
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1.5.2.2 Using Access Control for Network Applications 

Access control is the control that a node exercises over inbound 
logical link connections. The terms inbound and outbound 
refer to the direction of the logical link connection request. 

A node receives and processes inbound requests; it processes 
and sends outbound requests. This distinction is useful for 
discussing access control as it relates to VAX/VMS nodes in 
a network. Refer to appropriate DECnet documentation if the 
node to which you want to connect is not a VAX/VMS system. 

When DECnet-VAX software sends an outbound connection 
request in response to either a remote file access or a task- 
to-task communication operation, certain access control 
information may be necessary to connect successfully to 
the remote node and log in. As in logging in at your local 
VAX/VMS node, you can supply specific access control 
information in the form of a user name and password that the 
remote node recognizes. The remote node processes inbound 
connection requests containing this information to verify that 
you are a valid user of the system. For more information on 
inbound and outbound connection requests, see Section 2.10.2. 

Figure 1-10 illustrates the access control processing that takes 
place for a simple DCL command. 

When explicit access control information is not provided in 
the connection request, DECnet-VAX software uses the remote 
node name specified in the connection request as a key to locate 
the appropriate record in the local configuration database. This 
record contains default access control information applicable to 
the remote node. Your system manager creates this entry when 
establishing the configuration database. (Refer to Chapter 
additional information on the configuration database.) 

Depending on the privileges required by the object to which 
you want to connect and those of the user process (see Figure 
1-11), one of three possible sets of default access control 
information is sent to the remote node: default privileged, 
default nonprivileged, or null. Because these defaults are 
node parameters, all privileged operations requested with 
default access control for a given node run under the same 
default account. The same is true for nonprivileged operations 
requested with default access control. 
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Figure 1-10 Remote File Access Using Access Control String 
Information 



loop until timeout 
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If the target node is running DECnet-VAX, it can associate 
incoming connect requests with specific accounts other than the 
default DECnet account. This type of access is known as proxy 
login and requires that the originator of the request have a 
proxy account on the target node and that proxy login access be 
enabled at that node. Proxy login is described in Section 2.10.5. 

Figure 1-11 illustrates the access control processing that 
takes place for the same DCL command as in the example 
in Figure 1-10, except that the DCL command does not specify 
an access control string. 
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Figure 1-11 Remote File Access Using Default Access Control 
Information 



loop until timeout 
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1.5.2.3 Using Logical Names in Network Applications 

The use of logical names for network operations allows you 
to refer to network file and task specifications without using 
actual names that you give these elements. Logical names serve 
as a kind of shorthand for specifying all or a portion of a full 
file specification. By using logical names, you can pass file 
specifications defined at the DCL level to an executing image 
at run time. For example, logical names allow a program to 
access local or remote files without changing the program. You 
can also use logical names to conceal access control information 
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from other users by embedding it in a logical name defined 
in the process logical name table. Logical names provide 
convenient and powerful multilevel access control specification. 

The rules that govern the use of logical names for network 
operations are as follows: 

• Both the device name and node name in a full file 
specification string can be logical names. However, once 
a node specification is encountered during file parsing, a 
device name that follows is not translated locally. Instead, 
it is passed unaltered to the remote node, where it is subject 
to logical name translation. 

• A logical name appearing in the device name position in 
a file specification can supply any file specification string 
elements when translated. 

• A logical name appearing in the node name position can 
supply only a node-spec when translated. Therefore, its 
equivalence string must end with a double colon. 

• An access control string associated with a logical node name 
becomes the new access control string for the node-spec 

of the equivalence string, even if the node-spec contained 
an access control string. Thus, you can easily specify a 
default (or override any) access control string defined for the 
node-spec resulting from logical name translation. 

• After a logical node name is translated, the new node name 
becomes a candidate for logical node name translation. 

• A maximum of ten logical device name translations and ten 
logical node name translations is permitted. If you exceed 
these limits, an error message is returned. 

For more information on logical names, including examples of 
logical names that can be used for network applications, see the 
VAX/VMS DCL Dictionary. 
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This chapter presents networking concepts relevant to 
understanding the operation of the DECnet network, in terms 
of the functions performed by DECnet-VAX components and 
VAX PSI components. 

To establish your VAX/VMS operating system as part of the 
DECnet network, you must build and maintain a network 
configuration database, consisting of records that describe the 
specific network components your particular system requires. 
This chapter describes the DECnet-VAX components and their 
characteristics: nodes, circuits, lines, routing, logical links, 
objects, logging, and network access control. It also describes 
VAX PSI components used in communicating over a packet 
switching data network (PSDN): the X.25 protocol module, 
X.25/X.29 server modules, and X.25 access module. 

Chapter 3 discusses how you can use a DECnet-VAX utility 
program, the Network Control Program (NCP), to enter in your 
configuration database specific parameters for each network 
component your system will use. 


2.1 Nodes and DTEs 

A node is an operating system that uses DECnet software to 
communicate with other operating systems across a network. A 
VAX/VMS node uses DECnet-VAX software to communicate 
with other DECnet-VAX nodes and with any other DIGITAL 
operating system that supports DECnet. 

The X.25 equivalent of a node is a DTE (data terminal 
equipment). A DTE is a computer or terminal that uses VAX 
PSI software to communicate with remote nodes across a 
PSDN. You can configure your DECnet-VAX node as a DTE if 
VAX PSI software is installed on your node. 
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A DECnet-VAX node can also be an X.25 connector node, 
serving as a gateway that permits DECnet-VAX host nodes on 
an Ethernet to access a PSDN. To configure your DECnet-VAX 
node as a connector node, you must have VAX PSI software 
in multihost mode installed. To configure your DECnet-VAX 
node as an X.25 host node, you must have VAX PSI Access 
software installed but not VAX PSI software. 

This section describes the characteristics of nodes and the kinds 
of parameters you can associate with them. It also describes 
DTEs and indicates how you use X.25 protocol modules to 
define DTEs and the parameters related to them. Chapter 3 
discusses the use of NCP commands to establish the parameters 
for nodes and DTEs. 


2.1.1 Nodes 

The VAX/VMS operating system at which you are physically 
located is called the local node. By issuing network 
management commands at your local node, you can perform 
configuration, control, and monitoring functions that affect both 
the local node and other nodes in the network. The node on 
which network management functions are actually performed 
is called the executor node. Usually, the executor node will 
be the local node. You have the option, however, of entering 
at the local node one or more commands to be executed at a 
remote node. For those commands, the remote node serves as 
the executor node. 

To configure an operational network at the local node, you 
must establish configuration database entries for the local node 
and for all adjacent nodes that are connected by circuits. It is 
recommended that you specify names and addresses for all 
nodes in the network. Once you have done so, you can reach 
any other node by its name. 

To satisfy routing requirements, each node in the network must 
have a unique address. The node address is a number in the 
form 

area-number.node-number 
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The area-number is the number of the area in which the 
node resides and the node-number is the address of the node 
within that area. Each area number must be unique within 
the network and each node number unique within the area. If 
the area number is not specified in a node address, the area 
number of a remote node defaults to the area number of the 
executor node, and the area number of the executor defaults to 
the number 1. 

Node identification has two forms: a node address and a node 
name. A node address, a number in the format described 
above, is assigned to each node in the configuration database. 

A node name is an optional alphanumeric string. In the single¬ 
area network example in Chapter 1, the node assigned node 
address 1.11 is also identified by the node name BOSTON. 

In the multiple-area network example in Chapter 1, node 
BOSTON in area 2 has the node address 2.11. 

Because it is often easier to remember a name rather than an 
address, you may prefer to associate a name with an address. 
You can do so at any time. Note, however, that node names 
are known only to the local node network software while node 
addresses are known network-wide by the routing function. To 
avoid potential confusion, you should give each node a unique 
name that all nodes in the network will assign to that node and 
use to address it. 

Nodes on Ethernet lines can also be accessed under certain 
circumstances by their Ethernet addresses. All nodes connected 
to an Ethernet line are equally accessible, because the Ethernet 
is a multiaccess, broadcast device. Therefore, each node on 
an Ethernet is assigned a unique Ethernet physical address, 
which is set by the software at the node. You do not normally 
have to specify the Ethernet address of an individual node to 
configure your network or perform normal network operations. 
You do need to know a node's Ethernet physical address for 
service functions (such as downline load, circuit loopback 
test, and configurator operations). You can send a message to 
one, several, or all nodes on an Ethernet line simultaneously, 
depending on the Ethernet address used. To send a message to 
more than one node, use an Ethernet multicast address: either 
a multicast group address to reach a selected group of nodes, or 
a broadcast address to reach all nodes on the Ethernet. 
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The configuration database for the local node must contain 
certain information about the local node and may contain 
node information for all nodes with which you want to 
communicate. For the local node, you must specify the node 
address and should specify the node name and buffer size 
(which determines the largest size message the node can 
forward). You should also indicate or use the default value 
for the highest address the local node will recognize, and for 
the node type (which determines the routing capabilities of 
the local node). Optionally, you can specify data link control 
information for the local node. For remote nodes, you should 
specify names and addresses. You can also specify default 
information to be used in performing downline load or upline 
dump operations involving remote nodes. For any or all nodes, 
you can specify access control information and node counter 
event logging information. 

To update your configuration database with current information 
about remote nodes in your network, you can copy the names 
and addresses of remote nodes from the database of another 
node to which you have access. You can specify the node 
database (volatile or permanent) to be copied, and the local 
node database (either or both volatile and permanent) to 
which information is to be copied. You also have the option 
of clearing or purging your local node database before copying 
the remote node data, thus avoiding possible conflicts between 
original and updated data. The executor node information 
is preserved during the clear or purge operation. Being able 
to copy a node database permits you to keep your network 
information current even if you are part of a large network that 
changes frequently. Alternatively, if you configure your node 
without a permanent node database, you could obtain current 
information on other nodes in the network when required 
by copying it from another node (for example, from a node 
on your Ethernet that serves as a master by keeping its node 
database up to date). 

The data link control information you can specify for the local 
node controls certain characteristics of physical line operation, 
including the size and number of transmit and receive buffers 
and the number of circuits the local node can use. These 
values should be set to levels that ensure reasonable system 
operation. It is important to set the buffers for all nodes in 
the network to the same size. Otherwise, packets will be 
dropped when routed through nodes with smaller buffer sizes. 
A procedure for changing the size of buffers on all nodes in the 
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network without bringing down the whole network is given in 
Section 3.3.4.1. 

You can control the operational state of the local node and 
thereby control its active participation in the network. This 
control is usually a function of whether or not inbound logical 
link connections can be established or maintained with the local 
node. You can use this control to restrict the operation of the 
node or to shut it down altogether. 


2.1.2 DTEs 

A VAX/VMS operating system with VAX PSI software installed 
can function as a DTE capable of sending and receiving packets 
over the PSDN to which it is directly connected. To configure 
the local DTE, you must establish in the configuration database 
an X.25 protocol module entry, which identifies the PSDN your 
DTE is connected to and the characteristics of the subscription 
to the PSDN. The X.25 protocol module is described below. 
You must also establish X.25/X.29 server database entries that 
indicate the destinations of incoming X.25 and X.29 calls (see 
Section 2.7). 


2.1.2.1 X.25 Protocol Module 

The X.25 protocol module is a software component that 
controls the transmission of data packets over the PSDN. The 
configuration database for the X.25 protocol module identifies 
the PSDN to which your DTE is connected, defines the DTE, 
and specifies any user group to be associated with the DTE. 

The first step in configuring the X.25 protocol module is to 
identify the particular network to which your DTE is to be 
connected. When you specify the network, default values for a 
number of network-specific parameters that affect data-packet 
control are entered in the configuration database. Network 
defaults set the size and control the flow of data packets over 
switched virtual circuits, and control call setup and clearing of 
these circuits; they also control the transmission of resets and 
restarts over permanent and switched virtual circuits. 

You must then identify your local DTE or DTEs by DTE 
address. Each local DTE must have a unique address; the 
address format is determined by the network to which the 
DTE is connected. You have the option of configuring two 
DTEs, because a DTE is associated with a single line and VAX 
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PSI supports two lines. For each DTE, you can specify the 
operational state and maximum number of circuits that can be 
supported, and identify the associated line and the channels for 
outgoing calls. 

You should also identify any user group of which you are a 
member. A user group is an optional PSDN facility to which 
you can subscribe: a closed user group (CUG) permits two or 
more DTEs to communicate only with each other; a bilateral 
closed user group (BCUG) restricts communication to a pair 
of DTEs. Specify the unique name of your CUG or BCUG and 
associate with it the local DTE address and group number; for a 
BCUG, specify that the group type is bilateral. 


2.1.2.2 X.25 Connector and Host Nodes 

On an Ethernet, a VAX/VMS node that has VAX PSI software 
in multihost mode installed can serve as a connector node, a 
gateway that provides access to a PSDN for host nodes on 
the Ethernet. To configure your node with VAX PSI software 
in multihost mode, establish in the database an X.25 protocol 
module entry in the same way as for a DTE, then indicate 
in the X.25 server database the host destinations to which 
incoming calls are to be forwarded. 

If your node is on an Ethernet to which a multihost connector 
node is connected, your node can serve as a host node that uses 
the connector node to access a PSDN. A VAX/VMS host node 
must have VAX PSI Access software installed. To configure 
your node as a host node, you must establish in the database 
the X.25 access module (see Section 2.8) and indicate in the 
X.25 server database the destination on your node for incoming 
calls. 


2.2 Circuits 

Circuits are high-level communications data paths between 
nodes or DTEs; communication between nodes takes place 
over circuits. Circuits operate over physical lines, which are 
low-level communications paths (see Section 3.6). 
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2 . 2.1 
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Classes of DECnet—VAX Circuits 

DECnet-VAX employs four classes of circuits: DDCMP, Cl, 
Ethernet, and X.25. 

DDCMP circuits provide the logical point-to-point or multipoint 
connection between two or more nodes. There are currently 
three types of DDCMP circuits: point-to-point, multipoint 
control, and multipoint tributary. A point-to-point circuit 
operates over a corresponding synchronous or asynchronous 
DDCMP point-to-point line. Asynchronous lines can be either 
static (permanent) or dynamic (switched). 

Multipoint control circuits operate over synchronous DDCMP 
control lines. You can specify multiple circuits from the control 
(master) end of a control line, but each circuit must have a 
unique physical tributary address. On the tributary (slave) end, 
you can specify only one multipoint tributary circuit per line. 

Cl circuits are available only on those nodes that are attached 
to a CI-780 or CI-750 interconnect. Cl circuits are similar in 
many ways to DDCMP multipoint circuits, but use their own 
protocol. 

Ethernet circuits provide for multiaccess connection between a 
number of nodes on the same broadcast circuit. An Ethernet 
circuit differs from other DECnet circuits in that there is not 
a single node at the other end. An Ethernet circuit is a path 
to many nodes. Each node on a single Ethernet circuit is 
considered as being adjacent to every other node on the circuit 
and equally accessible. Every node must have a unique node 
identification: an Ethernet physical address. (Ethernet node 
addressing is described in Section 3.3.3.) Ethernet circuits use 
the Ethernet protocol. 

X.25 circuits use the X.25 level 3 protocol (the packet level) and 
provide for communication over PSDNs. VAX PSI provides 
X.25 circuits for use by PSI user application programs (also 
referred to as "native X.25 user programs") or by DECnet data 
link mapping (DLM). DLM permits the use of X.25 as a DECnet 
data link through the mapping of data link information between 
the DECnet Routing layer and the X.25 protocol module. The 
two types of X.25 circuits are X.25 native circuits and X.25 DLM 
circuits. 
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2 . 2.2 


Each X.25 circuit is a virtual circuit connecting a local DTE 
and a remote DTE. An X.25 virtual circuit can be either of the 
following: 

• A permanent virtual circuit (PVC), providing a permanent 
path between the local DTE and the remote DTE 

• A switched virtual circuit (SVC), providing a temporary path 
between the local DTE and the remote DTE 


The PVCs can be used by DECnet and native X.25 user 
programs for X.25 communications with a PSDN. SVCs can be 
used by both DECnet and native X.25 user programs, but only 
SVCs used by DECnet through data link mapping (DLM) need 
to be set up by means of NCP commands. VAX PSI sets up 
X.25 native SVCs with parameters taken from the X.25 protocol 
module component when calls on these circuits are requested. 
You do not need to use NCP to set up X.25 native SVCs. 

Just as you must specify the local node, you must also specify 
parameters for all DECnet circuits connected to the local node 
and all X.25 virtual circuits connected to local DTEs. 

You must identify each circuit by name and specify information 
that directly affects the circuit's operation. You can also specify 
the operational state of circuits connected to your local node or 
DTE. Thus you can control circuit traffic and perform service 
functions. The state of a circuit may ultimately affect the 
system's ability to reach an adjacent node or DTE. The circuit 
state can have a similar effect on routing. 

This section describes the circuit component. For a discussion 
of using NCP commands to specify circuits, see Chapter 3. 


DDCMP Circuit Devices 

DDCMP circuit devices can be synchronous or asynchronous. 
DECnet-VAX supports the following synchronous DDCMP 
circuit devices: 

• DMC11 

• DMR11 

• DMP11 
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• DMV11 

• DMF32 synchronous line unit 

The DMP11 and DMV11 are considered identical; all references 
to DMP11 are applicable to the DMV11. DECnet refers to 
either device as DMP11. The DMC11 and the DMR11 are 
point-to-point circuit devices and are considered identical. 

The DMP11 is either a point-to-point, multipoint control, or 
multipoint tributary circuit device. The DMF32 synchronous 
line unit is either a point-to-point or multipoint tributary circuit 
device. 

DECnet-VAX supports the following asynchronous DDCMP 
circuit devices: 

• DHU11 

• DHV11 

• DZ11 

• DZ32 

• DZV11 

• DMZ32 

• DMF32 asynchronous line unit 

The DZ11, DZ32, and DZV11 are represented by the 
mnemonic TT. The DHU11, DHV11, DMZ32, and DMF32 
asynchronous line units are represented by the mnemonic 
TX. The asynchronous circuit devices are point-to-point circuit 
devices used for static or dynamic asynchronous connections. 

Note that asynchronous DDCMP circuits need not be 
predefined for dynamic connections. They are established 
automatically during dynamic switching of terminal lines (see 
Section 2.3.2.3). 

Other DECnet implementations may support other DDCMP 
circuit devices. If a node in your network uses a circuit device 
other than one of these, refer to the appropriate DECnet 
documentation. This section provides a general discussion of 
point-to-point and multipoint circuits. The NCP section of the 
VAX/VMS Utilities Reference Volume lists DECnet circuit and 
line devices by name and operational category. 
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Every DDCMP circuit provides a logical, point-to-point 
connection between two nodes. The circuit operates over the 
corresponding DDCMP line (for example, the DMC11 circuit 
operates over the DMC11 line). The DMP11, operating as a 
multipoint control circuit, also provides a logical, multipoint 
connection (over one physical line) between a control station 
and several tributaries (as illustrated in Figure 2-1). The 
DMP11 and DMF32 can also operate as multipoint tributary 
circuit devices that provide a logical connection between a 
tributary and a control station. 

The following terms are used in describing the operation of 
multipoint circuits: 

• Control Station. The control station is the node at the 
controlling end of a multipoint circuit. It controls the 
tributaries for that circuit. 

• Polling. Polling is the activity that the control station 
performs on tributaries of a multipoint circuit. The control 
station regularly sends request messages to (that is, polls) 
each eligible tributary in the polling list. The request 
message asks the tributary if it has anything to send 
(essentially giving it permission to use the bus). 

• Tributary. A tributary is a physical termination point on a 
multipoint circuit that is not a control station. 

• Tributary Address. A tributary address is a numeric 
address that identifies a tributary node on a multipoint 
circuit. 

It is possible to connect both a multipoint control circuit and a 
multipoint tributary circuit to the same node. The node could 
then serve as the control station for one multipoint circuit and 
as a tributary for another multipoint circuit. 

The system manager must supply tributary addresses for a 
control station to use when polling each tributary in a polling 
list. 
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Figure 2-1 Multipoint Circuits and Associated Lines 
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2.2.3 Cl Circuit Device 

DECnet supports the CI-780 interconnect (on VAX-11/780, 
VAX-11/782, or VAX-11/785 processors only) and the CI-750 
interconnect (on VAX-11/750 processors only). All nodes 
connected to the same Cl bus can communicate directly with 
each other. Only one Cl controller per node is required. 
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2.2.4 


DECnet treats the Cl controller as a multipoint data link and 
requires a single entry in the line database and multiple entries 
in the circuit database. The line database entry describes the 
Cl controller (see Section 3.6). Each circuit database entry 
describes a virtual connection to a single remote node on the 
Cl. Cl multipoint circuits and DDCMP multipoint circuits differ 
in the following ways: 

• Each station on the Cl can talk directly to every other 
station. These stations are called tributaries and all stations 
are alike. There are no "control" and "tributary" stations as 
with DDCMP multipoint circuits. 

• There are no polling parameters on the Cl. 

• Cl circuits use their own communication protocol. 

If you plan to use a Cl circuit, you must first connect the device 
CNAO to the driver CNDRIVER. To connect CNAO to the 
CNDRIVER and load the CNDRIVER, add the following to the 
LOADNET.COM command procedure in SYS$MANAGER: 

$RUN SYS$SYSTEM:SYSGEN 
CONNECT CNAO/NOADAPTER 


Ethernet Circuit Device 

DECnet supports the DEUNA and DEQNA circuit devices 
(referred to as the UNA and QNA, respectively), which provide 
for multiaccess connections between many nodes on the same 
Ethernet circuit. The VAX/VMS system uses the DEUNA 
circuit device; the Micro VMS system uses the DEQNA, which 
performs similar functions. The UNA and QNA use the 
Ethernet protocol. Ethernet messages are sent over the Ethernet 
as datagrams, which means messages may be lost because of 
errors. DECnet provides for automatic retransmission of lost 
messages. The Ethernet device allows multiple users of the 
device at the same time; therefore, other users may be using 
the UNA or QNA on another type of protocol while DECnet is 
running. 
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2.2.5 Ethernet Configurator Module 

All nodes on an Ethernet circuit are logically adjacent, because 
the Ethernet is a multiaccess device. To obtain a list of all 
systems on an Ethernet circuit, you can use the Ethernet 
configurator module. The configurator module listens to system 
identification messages transmitted periodically by every 
DIGITAL-supported node on the Ethernet circuit, and builds 
the configuration list from the received messages. 

Approximately once every 10 minutes, each node on an 
Ethernet circuit that conforms to the DNA specifications 
transmits a system identification message (a hello message) to a 
multicast address that the configurator monitors. For a random 
distribution of nodes with possible loss of system identification 
datagrams, the configurator would require 40 minutes to collect 
all node addresses. In practice, the configurator normally 
requires about 12 minutes to complete a list. 

The Ethernet configurator module requires a default DECnet 
account. Use NCP commands to access and control the 
configurator module. The configurator runs as a separate 
process, and, once it is started, becomes available to all users on 
the system. The configurator module will continue to execute 
and will maintain and update its database of information on 
active nodes. 

When you request information on the current configuration 
of nodes on Ethernet circuits, the following is displayed for 
each system: its Ethernet physical and hardware addresses, the 
device connecting it to the circuit, maintenance functions it can 
perform, and the time of the last system identification message 
from the system. 


2.2.6 X.25 Circuit Devices 

X.25 circuits differ from DDCMP circuits in that there is no 
direct correspondence between circuit and line. All X.25 
circuits pass through the X.25 protocol handler module (see 
Section 2.1.2.1), which multiplexes circuits to lines that it 
"owns". There is no direct relationship between the name of 
an X.25 circuit and an X.25 line. One line is specified for each 
DTE. 
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All X.25 circuits are virtual circuits that connect a local DTE 
with a remote DTE. The association between DTEs can be 
permanent or temporary. X.25 PVCs are analogous to leased 
lines between the local DTE and the remote DTE. They are 
similar to DDCMP circuits in that both have predefined end 
points. 

X.25 SVCs are analogous to dialup lines. SVCs are set up 
only when there is data to transmit and are cleared when the 
transfer is complete. They are temporary paths between local 
and remote DTEs. 


2.2.7 X.25 DLM Circuits 

Data link mapping (DLM) circuits extend normal DECnet 
capabilities to include communication over a PSDN with other 
DECnet nodes connected to the PSDN. Data link mapping 
permits an X.25 virtual circuit to be used as a DECnet data link. 
A DLM circuit is owned by the executor node; the Routing 
layer has exclusive rights to use the circuit. A DLM circuit can 
be either a PVC or an SVC. A DLM SVC can be used for either 
incoming or outgoing calls. 

To establish a DLM SVC with a remote DTE, DECnet-VAX 
uses the DTE address of the remote node. Subaddresses can be 
used to limit the DLM calls accepted at the local DTE. DECnet- 
VAX will try to recall a number if previous attempts to establish 
a DLM SVC have not succeeded. The number and frequency of 
recall attempts can be regulated. 


2.3 Lines 


Lines provide physical communications and are the lowest level 
communications path. Circuits are high-level communications 
paths that operate over lines. 
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2.3.1 Classes of DECnet—VAX Lines 

DECnet-VAX supports four classes of lines: DDCMP, Cl, 
Ethernet, and X.25. A DDCMP line provides the physical point- 
to-point or multipoint connection between two or more nodes. 
A Cl line provides a high-speed connection between two or 
more nodes. An Ethernet line is a multiaccess connection 
between two or more nodes. An X.25 line is the physical link 
between your DTE and a PSDN. 

For DDCMP, Cl, and Ethernet configurations, each circuit is 
directly related to a corresponding line. For X.25 configurations, 
however, the circuits and lines do not correspond directly. X.25 
circuits are multiplexed to lines owned by the X.25 protocol 
handler module (see Section 2.1.2.1). 

Just as you must establish node and circuit parameters, you 
must also establish parameters for all physical lines connected 
to the local node or DTE. You must identify each line by name 
and specify information that directly affects the line's operation. 
You can control the operational state of the line, and thus 
control line traffic and perform service functions. The state of a 
, line may ultimately affect the reachability of an adjacent node 
or DTE, affecting the routing. 

This section describes the line component. For a discussion of 
using NCP commands to specify line parameters, see Chapter 3. 


2.3.2 DDCMP Lines 

DDCMP lines can be synchronous point-to-point or multipoint 
lines or asynchronous point-to-point lines. Asynchronous lines 
can be static (permanent) or dynamic (temporarily switched). 
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2.3.2.1 


DDCMP Line Devices 

DDCMP line devices can be synchronous or asynchronous. 
DECnet-VAX supports the following synchronous DDCMP line 
devices: 

• DMC11 

• DMR11 

• DMP11 

• DMV11 

• DMF32 synchronous line unit 

The DMC11 and the DMR11 are point-to-point line devices 
and are considered identical. The DMP11 is either a point-to- 
point, multipoint control, or multipoint tributary line device. 
The DMV11 is similar to the DMP11; DECnet refers to either 
device as the DMP11. The DMF32 synchronous line unit is a 
point-to-point or multipoint tributary line device. 

DECnet-VAX supports the following asynchronous DDCMP 
line devices: 

• DHU11 

• DHV11 

• DZ11 

• DZ32 

• DZV11 

• DMZ32 

• DMF32 asynchronous line unit 

The DZ11, DZ32, and DZV11 line devices are represented by 
the mnemonic TT. The DHU11, DHV11, DMZ32, and DMF32 
asynchronous line units are represented by the mnemonic TX. 
The asynchronous line devices are point-to-point line devices 
used for static or dynamic asynchronous connections. 

Note that asynchronous DDCMP lines need not be predefined 
for dynamic connections. They are established automatically 
when a dynamic asynchronous DDCMP connection is made 
(see Section 2.3.2.3). 
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Every DDCMP line provides a point-to-point connection 
between two nodes. Circuits, the actual communications path, 
operate over the line. The DMP11 and DMF32 also provide 
a multipoint connection between two or more nodes. In 
Figure 2-2 a multipoint line controlled by the DMP11 provides 
the physical connection between a control node and several 
tributary nodes. 

Figure 2-2 Multipoint Lines 
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It is also possible to connect two multipoint lines to the same 
node. The node could then serve as the control station for one 
multipoint line and as a tributary for another multipoint line. 
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Because a heterogeneous network such as the network example 
in this manual may have DDCMP line devices other than one 
of the above, you should be familiar with the entire range of 
devices and their impact on network management. Refer to the 
appropriate DECnet documentation if a node in your network 
uses a line device other than these. The NCP section of the 
VAX/VMS Utilities Reference Volume lists DECnet line devices 
by name and operational category. 


2.3.2.2 Static Asynchronous Lines 

A static asynchronous DDCMP connection is a permanent 
connection established between two nodes (such as a 
Micro VMS end node and a VAX/VMS router). The two nodes 
are connected by a physical line attached to a terminal port at 
each end (for example, port TTAO on the end node and port 
TXB7 on the router). A static asynchronous connection can also 
be made over a dialup line. 

Before the DECnet connection is made, the terminal lines 
must be converted to static asynchronous DDCMP lines. Each 
terminal port must have an asynchronous DDCMP line device 
installed, and the system manager at each node must load 
the asynchronous DDCMP driver, NODRIVER. The system 
manager at each node should insert the following command in 
the LOADNET.COM command procedure. 

$ SET TERMINAL/PROTOCOL=DDCMP device-name: 

The device-name is the name of the appropriate terminal 
port. For example, the Micro VMS manager should specify the 
command 

$ SET TERMINAL/PROTOCOL=DDCMP TTAO: 

and the VAX/VMS manager should specify 

$ SET TERMINAL/PROTOCOL=DDCMP TXB7: 

Each system manager should then specify the appropriate line 
and circuit commands in the configuration database to turn 
the line and circuit on for DECnet use. (For examples of the 
commands required for static asynchronous connections, refer 
to the description of installing static asynchronous lines in 
Chapter 5.) 
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2.3.2.3 Dynamic Asynchronous Lines 

A dynamic asynchronous line differs from a static asynchronous 
line or other DECnet-VAX line in that it is normally switched 
on for network use only for the duration of a dialup connection 
between two nodes. When the telephone is hung up, the line 
reverts to being a terminal line. 

Figure 2-3 illustrates a typical configuration in which dynamic 
asynchronous switching occurs over a dialup line. The local 
node in the figure is a standalone MicroVAX system; the remote 
node is a VAX-11/780. After the user at the local node dials in 
to the remote node, he can cause the lines connected to terminal 
ports TTA1 and TXB1 to be switched to dynamic asynchronous 
DDCMP lines for use in DECnet communications. 

Dynamic switching of terminal lines to asynchronous DDCMP 
lines can occur provided both nodes have DECnet-VAX 
licenses installed. The system manager at each node must have 
loaded the asynchronous driver NODRIVER and installed the 
privileged shareable image DYNSWITCH. The system manager 
at the remote node must have enabled virtual terminals on the 
system and, in particular, for the line over which you are going 
to log in. 

The procedure for dynamic switching of lines is as follows: 

1 You should log in to the Micro VMS system through the 
terminal port TTAO, causing a process (PROCESS—L) to be 
created on your system. 

2 You must issue the following DCL command: 

$ SET HOST/DTE[/DIAL=NUMBER:number] TTA1: 

This command causes the local system to function as 
a terminal emulator, and causes the modem to dial the 
number of the remote system. The terminal emulator 
permits the local processor to function as though it were 
a terminal line: characters can be read from one port 
and written to another port. In this figure, the terminal 
emulator on the MicroVAX reads characters from port TTAO 
and writes characters to port TTA1. Note that the /DIAL 
qualifier in the SET HOST/DTE command is optional and 
works only if you have written a program to dial your 
modem. The default program supplied with VAX/VMS dials 
a DF03 modem. 
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Figure 2-3 Dynamic Switching of Asynchronous DDCMP Lines 
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3 Once the dialup connection is made and you receive the 
remote system welcome message, you should perform the 
regular procedure for logging in to your account on the 
remote node. In this example, you would supply your 
username and password to the VAX/VMS system. 

4 When you log in over a modem line, a process (PROCESS— 
R) is created at the remote node and connected to a virtual 
terminal as well as the physical terminal. The virtual 
terminal permits PROCESS—R to continue running even if 
the physical terminal is disconnected (for example, if you 
lose the carrier signal on your telephone line). 

5 You can then initiate dynamic switching by specifying the 
following DCL command from your account on the remote 
node: 

$ SET TERMINAL/PROTOCOL=DDCMP/SWITCH=DECNET 

6 When the SET image at the remote node recognizes the 
/SWITCH=DECNET qualifier, it calls the shareable image 
DYNSWITCH. DYNSWITCH verifies that the device is 

a virtual terminal and then sends an escape sequence to 
the terminal emulator running on the MicroVAX. The 
escape sequence notifies the terminal emulator that the 
line connected to the remote terminal port is becoming an 
asynchronous DDCMP line. 

7 When the terminal emulator at the local node receives the 
escape sequence, it calls the image DYNSWITCH, which 
causes the line connected to terminal port TTA1 to be 
switched to an asynchronous DDCMP line. It assigns a 
channel to the network and supplies the appropriate line 
and circuit entries to the NCP volatile database at the local 
node. (Note that the modem line is not dropped; redialing 
is not required.) 

8 The asynchronous DDCMP protocol on the local node then 
sends a DDCMP start message to DYNSWITCH on the 
remote node. DYNSWITCH at the remote node disconnects 
the physical terminal from the virtual terminal, and causes 
the line connected to the physical terminal port (in the 
figure, the port TXB1) to be converted to an asynchronous 
DDCMP line. DYNSWITCH assigns a channel to the 
network and supplies the appropriate line and circuit 
parameters to the volatile database to start up the line and 
circuit. 
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9 After DECnet is started on the local node, the terminal 
emulator is exited and control is returned to the local node 
with the following message: 

*/, REM - control returns to local-node-name: 

A prompt appears on the local terminal and you can then 
use DECnet to perform operations over the network. 

10 If the terminal emulator does not recognize escape 
sequences, you must specify the /MANUAL qualifier 
in the SET TERMINAL command indicated in step 5. 

The /MANUAL qualifier prevents DYNSWITCH at the 
remote node from sending the escape sequence. Instead, 
DYNSWITCH sends the following message to the local node 

% SET-I-SWINPRG The line you are currently logged in 
over is becoming a DECnet line 

After receiving this message, if you decide not to switch 
the line, you can type CTRL/C or CTRL/Y to abort the 
switch. If you want to continue the switch, you should exit 
the terminal emulator and switch your terminal line to an 
asynchronous DDCMP line manually by specifying: 

$ SET TERMINAL/PROTOCOL=DDCMP TTA1: 

and entering NCP commands to turn your line and circuit 
on. DYNSWITCH waits 60 seconds for the DDCMP start 
message and then times out the switch. 

Note that the SET TERMINAL command is a VAX/VMS 
DCL command. If you are on a non-VAX/VMS node, you 
should specify the equivalent function for your system. 

11 When you hang up the line, it is switched back to a terminal 
line. (DECnet-VAX automatically clears the line and circuit 
entries from the volatile database). Alternatively, you can 
switch the asynchronous line back to a terminal line by 
issuing an NCP command to turn the line or circuit off. 

If you specified the /NOHANGUP qualifier in the SET 
TERMINAL command in step 5, the modem signal is not 
dropped if you specify an NCP command to turn off the 
DECnet line. You will not have to redial the connection 
to the remote node when you want to convert your line to 
DECnet use. The modem signal is dropped when you hang 
up the telephone. 
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For an example of the commands required for dynamic 
switching, see the description of installing dynamic 
asynchronous lines in Chapter 5. 

NCP command parameters required for asynchronous 
connections are described in Chapter 3. Security for dynamic 
asynchronous connections is summarized in Section 2.10. 


2.3.3 Cl Line Device 

The CI-780 and CI-750 lines are high-speed devices, each of 
which provides a connection between two or more nodes. If 
you plan to run DECnet over a Cl, you must first connect the 
device CNAO to the driver CNDRIVER. To connect CNAO to 
the CNDRIVER and load the CNDRIVER, add the following to 
the LOADNET.COM command procedure in SYS$MANAGER. 

$RUN SYS$SYSTEM:SYSGEN 
CONNECT CNAO/NOADAPTER 


2.3.4 Ethernet Line Device 

A VAX/VMS Ethernet node is connected to the Ethernet line 
by the DEUNA communications controller, a transceiver, 
and a transceiver cable. A Micro VMS Ethernet node uses 
the DEQNA controller to perform the same functions as the 
DEUNA controller. The Ethernet line device that provides the 
physical connection between two or more nodes on the same 
Ethernet cable is the UNA, for a VAX/VMS node, or the QNA, 
for a Micro VMS node. The UNA and QNA use the Ethernet 
line protocol. The Ethernet circuit operates over the Ethernet 
line. 

A particular Ethernet node is identified by the Ethernet 
hardware address of its line device; this hardware address 
is stored in read-only memory in the DEUNA or DEQNA. 
When DECnet starts an Ethernet line, it causes the DEUNA or 
DEQNA connected to the line to construct an Ethernet physical 
address for the node (see Section 3.3.3). Conditions that cause 
the DEUNA or DEQNA to reset the physical address to the 
original hardware address are shutting off machine power or 
changing the state of the Ethernet line to OFF. 
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2.3.5 X.25 Line Devices 

VAX PSI supports the following line devices: 

• DMF32 synchronous line unit 

• DUP11-DA 

• DPV11 

• KMS11-BD 

• KMS11-PX/PY 

The DPV11 is equivalent to a DUP11. The DMF32 synchronous 
line unit is a point-to-point or multipoint tributary circuit 
device. The DUP11-DA is a low-speed synchronous interface. 
The combination of the KMS11-BD controller hardware and the 
X.25 level 2 microcode provides a medium-speed synchronous 
interface called the KMX. The KMS11-BD supports eight lines, 
only two of which can be active simultaneously. Similarly, the 
combination of the KMS11-PX controller hardware and the 
X.25 level 2 microcode provide a medium-speed synchronous 
interface called the KMY, supporting one line. The KMV11 is 
equivalent to a KMY. 


2.4 Routing 

Routing is the network function that determines the path or 
route along which data (called "packets" in this context) travels 
to its destination. The Routing layer of DECnet handles routing 
functions. Because the need for routing pervades network 
operation, as much as possible is done in software to relieve the 
user from worrying about the configuration of the network. 

As system manager, however, you need to be concerned with 
the configuration of the network in terms of routing. You must 
configure each network node as either a routing or a nonrouting 
node, and you have the option of dividing the whole network 
into different areas. In addition, certain parameters in the 
configuration database permit a degree of indirect control over 
network routing, but, for most networks, the default values of 
these parameters are reasonable. 
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2.4.1 


For very large networks, it may be helpful to have a network 
manager oversee the operation of the network as a whole. 

The network manager could insure that all node addresses are 
unique and that routing control parameters provide for efficient 
data flow through the network. 

This section explains the different types of routing and 
nonrouting nodes and configurations, describes the levels 
of routing, and summarizes special routing techniques used 
with Ethernet. It also introduces basic terms and concepts 
involved in routing control. The NCP command parameters 
that affect routing are discussed in Chapter 3. 


Routing and Nonrouting Nodes 

Routing nodes (routers) are nodes that can send and receive 
packets and route packets from one node to another. Routers 
have two or more circuits. Routers regularly receive and 
maintain information about other nodes. They perform the 
routing operation by associating a circuit with the destination 
node for the packet and transmitting that packet over that 
circuit. Routers can use DDCMP, Cl, Ethernet, or X.25 circuits 
as their data links. 

In a multiple-area network, all routers in a particular area can 
route packets within the area; certain of these routers can also 
route packets to and from other areas. The two kinds of routers 
used in area routing configurations are level 1 routers and level 
2 routers. 

The level 1 router performs intra-area routing within a single 
area of the network. Note that if all nodes are configured in the 
same area, the whole network is considered as a single area, 
and all routers are level 1 routers. The level 2 router performs 
intra-area routing within its own area and interarea routing 
between its area and one or more other areas of the network. 

Nonrouting nodes (end nodes) contain a subset of network 
software that permits them to send packets or receive packets 
addressed to them, but not to route packets to other nodes. 

End nodes have a single circuit connecting them to the rest of 
the network. They do not send or receive information about 
network configurations. If two end nodes are connected by a 
nonbroadcast circuit, these nodes constitute the entire network. 
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2.4.1.1 


On an Ethernet, if there are two or more routers, one router 
is elected the designated router to provide message routing 
services for end nodes on the Ethernet. If no routers are 
available, Ethernet end nodes can communicate with each other 
directly, by sending a packet out over the Ethernet and then 
waiting, until the timeout, for a reply. However, routers are the 
only Ethernet nodes that can route messages to nodes off of the 
Ethernet. 


Types of DECnet Nodes 

DECnet supports a variety of types of nodes developed during 
different phases of DNA implementation. Phase II, III, and IV 
nodes can all exist on a network. The following types of nodes 
can be configured as being adjacent to each other: 

• Phase II/Phase II 

• Phase II/Phase III 

• Phase Ill/Phase III 

• Phase Ill/Phase IV 

• Phase IV/Phase IV 

Phase II nodes can communicate with each other as long as 
there is a physical data link between them. They support only 
point-to-point connections. There is no Phase II support for 
Ethernet. 

Phase III DECnet introduced adaptive routing, which 
allows a reasonably large number of nodes to communicate 
conveniently. A network composed of Phase III nodes is 
limited to a practical size of approximately 100 nodes, because 
of the overhead of routing update messages that have to be 
exchanged among routers. (The design limit for the address of 
a DECnet-VAX Phase III node is 255; this limit may vary for 
other DECnet Phase III systems.) Phase III introduced routers 
and end nodes. Phase III depends on data links that guarantee 
delivery of messages in order to accomplish initialization among 
routers. Therefore, there is no Phase III support for Ethernet. 

Phase IV DECnet permits the configuration of very large 
networks and expands the types of data links available for use. 
Phase IV supports area routing, which allows configuration 
of a network of up to 63 areas, each containing up to 1023 
nodes. Phase IV software supports Ethernet circuits, as well as 
DDCMP, Cl and X.25 circuits. 
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Phase IV nodes can speak to Phase III nodes. Certain 
restrictions apply, however, in a mixed Phase Ill/Phase IV 
network: 

• A Phase III node should not be included in a path between 
Phase IV nodes. 

• A Phase III node in a Phase IV multiple-area network 
should not be linked with nodes outside its own area. 

• Routing initialization passwords (described in Section 2.10.1) 
are required when a Phase III node is initialized in a Phase 
IV network. 

Restrictions on the use of Phase III nodes in Phase IV networks 
are discussed in detail in Section A.5. 


2.4.1.2 DECnet-VAX Phase IV Nodes 

DECnet-VAX Phase IV nodes are either of the following two 
types: 

• Phase IV routers. These nodes deliver packets to and 
receive packets from other nodes, and route packets from 
other source nodes through to other destination nodes. 

They use Ethernet, DDCMP, X.25, and Cl circuits. In an 
area network configuration. Phase IV routers exist at two 
routing levels: 

— The level 1 router, which performs routing within a 
single area. The node type is ROUTING IV. 

— The level 2 router, which performs routing within its 
own area and to and from other areas. The node type is 
AREA. 

• Phase IV nonrouting nodes (end nodes). These nodes 
deliver packets to other nodes and receive packets from 
other nodes, but do not route packets through. They can be 
attached to an Ethernet, DDCMP, X.25, or Cl circuit. The 
node type is NONROUTING IV. 
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DECnet-VAX Phase IV nodes can also communicate with the 
other types of nodes supported by DECnet. Area numbers are 
dropped when a Phase IV node communicates with a node 
that is not a Phase IV node. A Phase IV node will add its 
executor area number to the node address of a message that it 
receives from a Phase III node. Nodes with which Phase IV 
DECnet-VAX nodes can communicate include: 

• Phase III routers. These nodes deliver packets to and receive 
packets from other nodes, and route packets from other 
source nodes through to other destination nodes whose 
addresses are less than 256. They use DDCMP, X.25, and 
Cl circuits, but do not support Ethernet circuits. 

• Phase III nonrouting nodes (end nodes). These nodes send 
packets to other nodes and receive packets from other 
nodes, but do not route packets through. These nodes 
cannot support the Ethernet. DECnet-VAX never provided 
this type of node, but can communicate with Phase III end 
nodes (for example, RSX Phase III end nodes). 

• Phase II nodes. These nodes can send packets to adjacent 
Phase III routers or to other adjacent Phase II nodes. 
However, Phase II nodes can send packets only in point-to- 
point configurations. In addition, a Phase III node cannot 
communicate with a Phase II node through another Phase 
III node. 


2.4.1.3 Routing Features of DECnet—VAX License Options 

The DECnet-VAX license you purchase determines the types 
of nodes you can configure. DECnet-VAX offers the option of 
installing a key for either of two kinds of DECnet-VAX license. 


• The full function license permits the node on which the 
appropriate key has been installed to be configured as either 
a router or an end node. 

• The end node license permits the node on which the 
appropriate key has been installed to be configured only as 
an end node. 

Both licenses permit the use of any kind of data link (DDCMP, 
Cl, Ethernet, X.25). Installation of the DECnet-VAX license key 
is described in Section 6.1. 
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2.4.2 


A configuration consisting only of end nodes offers certain 

advantages: 

• Less use of the central processor is required for routing. 

• Data link efficiency is increased: there is no routing 
overhead and no route-through traffic occurs over the 
circuit. 

End nodes also involve the following limitations: 

• The user on an end node cannot directly see the status of 
other nodes in the network, because end nodes rely on 
routing nodes to maintain that information. However, a 
Phase IV end node can communicate with all nodes in the 
network, including nodes outside its own area. 

• At most, only one circuit is allowed to be active. If that 
one link to the network fails, no alternative connection is 
available until the system manager turns on a standby data 
link, if one exists. 


Area Routing 

Phase IV DECnet permits implementation of very large 
networks through the use of area routing techniques, while 
still supporting configuration of smaller networks that are not 
divided into areas. The network manager has the option of 
partitioning a large network into areas. Each area is a group 
of nodes. Nodes are grouped together in areas for hierarchical 
routing purposes. Hierarchical routing involves the addition of 
a second level of routing to the network. Routing within an 
area is referred to as level 1 routing; routing between areas is 
called level 2 routing. 

Area routing offers the following advantages: 

• It permits configuration of very large networks of more than 
1023 nodes. 

• It requires less routing traffic, restricting routing overhead 
between areas to the level 2 routers. Level 1 routers 
exchange routing information only about nodes in their own 
area. 
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• It allows different organizations to manage their nodes 
separately within a large network. 

• It makes the merging of existing networks easier. 

When a level 1 router receives a packet destined for a node 
in another area, it uses level 1 routing to send the packet to 
the nearest node within its own area that can perform level 2 
routing. That router forwards the packet by level 2 routing to a 
level 2 router in the destination area, which in turn sends the 
packet by level 1 routing to the destination node in its area. 

Note that if two or more level 2 routers exist in the same area, 
each level 1 router in that area sends packets destined for other 
areas to the nearest level 2 router, regardless of which level 2 
router is closest to the destination area. The level 1 router has 
no access to level 2 routing information. 

Each area in the network is assigned an area number. Every 
node in the area is uniquely identified by the addition of its area 
number as a prefix (followed by a period) to its node number. 
For example, node 15 in area 7 is addressed as node 7.15. The 
node number must be unique within the area, but may be used 
again within another area. Thus node identification within an 
area is independent of node identification within other areas. 

Phase IV DECnet permits configuration of a maximum of 63 
areas (areas 1 through 63), each containing up to 1023 nodes. A 
Phase IV node address is a 16-bit number: the most significant 
6 bits define the area number, and the least significant 10 bits 
specify the node number within the area. The Phase IV node 
address can be converted to its decimal equivalent for use in 
commands, such as COPY and MAIL commands, that do not 
recognize the area prefix (the conversion procedure is given in 
Section 3.7.2). It can be converted to its hexadecimal equivalent 
for use in determining the Ethernet physical address of the 
node (the conversion procedure is given in Section 3.3.3.2). 

You assign the node address to your own node when you 
configure it. If you do not specify the area number when 
addressing a remote node, that node is assumed to be in the 
same area as your local node. 

In a network not divided into multiple areas, each router 
performs level 1 routing throughout the network. 
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2.4.3 


The characteristics of level 1 and level 2 routing nodes are 
described in the following section. Appendix A presents 
rules for configuring hierarchical networks using area-routing 
techniques. This appendix also describes the configuration of 
mixed area networks, involving Phase III and Phase IV nodes, 
and recommends procedures for converting a nonarea network 
to an area network. 


Level 1 and Level 2 Routers 

An area can contain many level 1 routers and end nodes, 
and must contain at least one level 2 router to provide the 
connection to other areas. A level 1 router acts as a standard 
routing node. It keeps information on the state of nodes within 
its own area. Level 1 routing nodes and end nodes obtain 
access to nodes in other areas through a level 2 router residing 
in their own area. 

A level 2 router keeps information on the state of nodes in its 
own area and also information on the cost and hops involved 
in reaching other areas. (The logical distance between adjacent 
level 2 nodes is one hop.) The level 2 router always routes 
packets over the least cost path to a destination area. Level 2 
routers have the following characteristics: 

• Level 2 routers connect areas together. 

• Level 2 routers also act as level 1 routers within their own 
area. 

• Each level 2 router in a network must be physically 
connected to at least one other level 2 router. 

• A level 2 router serves as a level 1 router when it is not 
physically connected to another level 2 router. 

• All level 2 routers must be connected in such a way that 
they create a network of their own. 

• Level 2 routers exchange level 2 routing messages among 
themselves. 

• In any given area, there can be more than one level 2 router. 

• Each level 2 router indicates it is the nearest level 2 router 
to each level 1 node in its own area, but each level 1 node 
decides what its level 2 router is on the basis of cost. 
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2.4.4 Ethernet Routers and End Nodes 

Two special concepts are involved in routing over an Ethernet 
circuit: the designated router and end node caching. 


2.4.4.1 Ethernet Designated Routers 

If there are two or more routers on the same Ethernet, one of 
them is elected as the designated router. By convention the 
router with the highest numerical priority (set as a CIRCUIT 
characteristic in its database) is elected router for the circuit. In 
case of a tie, the node with the highest address is elected as 
the designated router. The function of the designated router is 
to route messages over the Ethernet on behalf of end nodes. 

A designated router is elected even if there are no end nodes 
currently on the Ethernet. 

Ethernet end nodes can also exchange messages directly 
without using a router. Routers are needed, however, when 
messages are to be routed to nodes off the Ethernet. 

Ethernet end nodes are informed of the identity of the 
designated router on that Ethernet. End nodes transmit 
multicast hello messages, so that routers know of their presence 
on the Ethernet. End nodes keep no information about the 
network configuration, except that they are permitted to keep a 
cache of nodes within their area that they may address directly 
on the Ethernet, rather than going through a router (see the 
description of Ethernet end node caching below). Thus an end 
node may send a packet directly to another Ethernet end node, 
if the address has been cached, or it may send a packet to the 
designated router for forwarding. 

Note that end nodes can exist on an Ethernet without a router. 
When an end node on the Ethernet wishes to communicate 
with another end node, and notes that no designated router 
exists, it will always send the packet directly to the addressed 
node. If the addressed node is active, the sender will receive 
a reply; if the addressed node is not available, a timeout will 
occur. 
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2.4.4.2 Ethernet End Node Caching 

End nodes normally send packets by means of a router. To 
minimize the space and time overhead involved in the routing 
function on Ethernet circuits, a caching mechanism is available 
that takes advantage of the fact that nodes on an Ethernet are 
logically one hop away from each other (one hop is the distance 
between two adjacent nodes). 

When a designated router is present and an end node is ready 
to send a packet to a node for the first time, the end node 
sends the packet to the designated router. When there is 
no designated router on the circuit, the end node sends the 
packet directly, in expectation that the other node is there. If a 
response is received, the end node examines the received packet 
to see if the "on-Ethemet" bit is set (the bit is checked even if 
the first packet went to the designated router). If the bit is not 
set, no action is taken; if the bit is set, then the next packet can 
be sent directly, rather than by means of the designated router. 


2.4.4.3 Area Routing on an Ethernet 

All nodes on an Ethernet need not be in the same area; more 
than one area can be configured on a single Ethernet. The areas 
on the same Ethernet are logically separate from each other. 
When two level 1 routing nodes on an Ethernet are configured 
in different areas, the nodes do not communicate directly with 
each other. Each level 1 router communicates with a level 2 
router in its own area, which sends the message to a level 2 
router in the other area. The level 2 router that receives the 
message then transmits it to the second level 1 router. Area 
routing on an Ethernet is illustrated in Section A.6. 


2.4.5 Routers and End Nodes on Cl Data Links 

Nodes in a VAXcluster using a Cl data link can be configured 
as routers or end nodes. 


2.4.5.1 Cl End Nodes 

A two-node VAXcluster using a Cl data link can be configured 
using end nodes only, but at least one router is required if 
additional nodes are configured in the cluster. The Cl protocol 
does not include the multiaccess capabilities of the Ethernet 
protocol. 


2-33 







DECnet-VAX Components and Concepts 


2.4.5.2 Cl Routers 

One or more Cl routers are necessary if a VAXcluster consists 
of three or more nodes. Cl circuit devices are treated as though 
they were multipoint devices (like the DMP device) rather 
than as multiaccess devices such as the Ethernet circuit device. 
Although only one router is required in a cluster of more than 
two nodes, having more routers in the cluster environment 
increases the overall availability of the network within the 
cluster. 

If the VAXcluster configuration includes end nodes as well 
as routers, a backup, higher-cost circuit could be provided 
for each end node. This backup circuit could take over if the 
primary circuit connecting the end node to its router fails (see 
Section 3.7.6). 

Note that end nodes communicating through a router send all 
data through that router even though they are connected to the 
same Cl. The best performance and availability are achieved by 
defining all VAXcluster nodes as routers if the Cl is used as the 
datalink. 


2.4.6 Routing Concepts and Terms 

This section briefly explains routing concepts and defines those 
routing parameters that provide some control over network 
routing. Use of NCP commands to set these routing parameters 
is described in Chapter 3. A more detailed explanation of 
routing concepts and the routing algorithms for the routing 
layer can be found in the Introduction to DECnet manual. 

The following terms are used to describe DECnet routing and 
routing parameters: 

• Hop. The logical distance between two nodes is measured 
in hops. The distance between two adjacent nodes is one 
hop. 

• Path. A path is the route a packet takes from source to 
destination. 

• Path length. The path length is the number of hops along a 
path between two nodes; it is the number of circuits a packet 
must travel across to reach its destination. The path length 
never exceeds a maximum number of hops, a value that the 
system manager sets relative to the size and configuration of 
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each network. For an area network, the network manager 
should determine the maximum number of hops permitted 
within an area and between areas. 

• Cost. The cost is an integer value assigned to a circuit 
between two adjacent nodes. It is usually proportioned 
to transmission delay. Each circuit has a separate cost. In 
terms of the routing algorithm, packets are routed on paths 
with the least cost. Nodes on either end of a circuit can 
assign different costs to the same circuit. 

• Path cost. The path cost is the sum of the circuit costs along 
a path between two nodes. The path cost never exceeds a 
maximum cost value the network manager specifies for the 
network. For an area network, the network manager sets 
the maximum cost for a path within an area, and for a path 
between areas. 

• Reachable node. A reachable node is a destination node 
to which the Routing layer on the local node has a useable 
path; that is, the path does not exceed the values for 
maximum cost or hops between nodes specified in the 
executor database. For an area network, a reachable area 
is one to which the path does not exceed the values for 
maximum cost or hops between areas set in the executor 
database. 

• Maximum visits. The maximum number of nodes through 
which a packet can be routed before arriving at the 
destination node is referred to as the maximum number 

of visits the packet can make. If a packet exceeds the 
maximum number of visits, the packet is dropped. 


When configuring a network, the network manager establishes 
the routing parameters for circuit cost control and route-through 
control. These parameters allow you to control the path that 
data is likely to take when being transmitted through the 
network, and also to minimize congestion at particular nodes 
in the network. For most networks, the default values for these 
parameters are reasonable. 

As network manager, you must assign a circuit cost to every 
circuit that connects the local node with adjacent remote nodes. 
These costs serve as values that DECnet software uses to 
determine the path over which data is transmitted. When the 
node is up and running, you can dynamically change the cost 
of a circuit to a higher or lower value. Altering circuit costs 
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2.4.7 


can change packet routing paths and thereby affect the use and 
availability of network circuits and resources. 

Along with defining circuit costs, you should also consider 
the path lengths and total path cost for routing packets over 
the network. For routing purposes, DECnet software identifies 
the least costly path to each destination in the network. As 
network manager, you are responsible for defining both the 
maximum cost of all circuits and the maximum hops that a 
packet can take when routed to the destination node. If you are 
configuring an area network, you should define the maximum 
cost and hops for a path between nodes within your own area, 
and the maximum cost and hops for a path between level 2 
routers in the whole network. 

The Routing layer in each node of the network uses congestion- 
control algorithms to maintain an efficient level of routing 
throughput. In addition, as network manager, you can maintain 
indirect control over routing throughput by defining the 
maximum visits a packet can make before being received by 
the destination node. Packets that have exceeded this limit are 
discarded. This control prevents packets from looping endlessly 
through the network. 


Routing Messages 

Adjacent routing nodes exchange routing update messages. A 
routing update message is a packet that contains information 
about the cost and hops for each node in the network. In an 
area network, a level 1 router sends routing update messages 
about all nodes within its own area to adjacent routers in the 
area. Level 2 routers send routing update messages containing 
cost and hop information about all areas to adjacent level 2 
routers in the network. 

Whenever this routing information changes (for instance, 
when a circuit goes down) new routing messages will be sent 
automatically. For example, if someone were to change the 
state of a circuit, rendering a remote node unreachable, this 
change would be reflected automatically in the routing update 
messages exchanged by the routing nodes. 
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2.4.7.1 Segmented Routing Messages 

The number of nodes that Phase IV DECnet can support in a 
single-area network is increased to a maximum of 1023 from 
the limit of 256 for Phase III DECnet. This increase is due 
to changes in the routing update messages. In Phase III, a 
legal network was restricted in size to the number of nodes 
for which cost and hop information could be fit into a single 
routing update message. Furthermore, Phase III routers had to 
send complete updates containing information about all nodes, 
whether or not their reachability had changed. Phase IV allows 
segmented routing messages to be sent, that is, messages that 
contain only the information that has been changed. Phase IV 
also permits routing updates to be sent in multiple messages. 
Therefore, the size of the routing messages and the number of 
buffers required to receive them are reduced. 


2.4.7.2 Timing of Routing Message Transmissions 

The network manager can set a timer for transmission 
of routing messages, controlling the intervals at which 
nonconfiguration change routing updates are transmitted. 

The routing timer controls the frequency of transmission of 
these messages on non-Ethernet circuits. The broadcast routing 
timer controls their frequency for Ethernet circuits. Expiration 
of the broadcast routing timer causes the local node to send a 
multicast routing configuration message to all routers on the 
Ethernet. 


2.5 Logical Links 

DECnet uses a mechanism called a logical link to allow 
communication between processes running on either the 
same node or on separate nodes in the network. A logical link 
carries a stream (consisting of regular data and interrupt data) 
of full-duplex traffic between two user-level processes. Each 
logical link is a temporary data path that exists until one of the 
two processes terminates the connection. 

The system manager can control various aspects of logical 
link operation on the local node. These include defining the 
maximum number of links that can be active, setting timers 
that control Network Services Protocol (NSP) operation, and 
specifying the number of packets that can be transmitted on a 
logical link before an acknowledgement is received (the pipeline 
quota). In addition, you can selectively disconnect active links 
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on the local node while the network is running. To verify that 
the links have been disconnected, you can display information 
on the status of the links. 

To control logical link activity related to NSP, you can specify 
parameters that regulate the duration of NSP connect sequences 
and inactivity intervals, and the frequency with which NSP 
retransmits messages. The timers you can set include: 

• The incoming timer, which protects the local node against 
the overhead caused by a local process that does not 
respond to an inbound connection request within a specified 
interval. 

• The outgoing timer, which protects the local node against 
the overhead caused by a connection request to a remote 
node that does not complete within a specified interval. 

• The inactivity timer, which protects the user against a link 
that may be permanently unusable, by setting the frequency 
with which DECnet tests an inactive link. 

You should normally use default values for the parameters 
which regulate the frequency of NCP message retransmission 
at the local node, unless you need to change the operating 
characteristics of a particular logical link. The retransmit time is 
affected by the estimated delay in round-trip transmission 
between the local node and the node with which it is 
communicating. The delay weight and delay factor parameters 
are used to calculate new values for this estimated delay. The 
retransmit factor parameter governs the number of times NSP 
will try to retransmit on a logical link. 


2.6 Objects 

Objects provide known general-purpose network services. An 
object is identified by object type, which is a discrete numeric 
identifier for either a user task or a DECnet program such as 
NML or FAL. The DECnet network software uses object type 
numbers to enable logical link communication using NSP. The 
system manager is responsible for supplying information for 
those objects, both user-defined and network objects, that can 
be used over the network. 
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2 . 6.1 


For VAX PSI network operations, you are responsible for 
identifying objects by name, and establishing command 
procedures to be initiated when incoming X.25 calls to the 
objects arrive. 


DECnet—VAX Objects 

When setting up the network, you must supply information for 

two general kinds of DECnet-VAX objects: 

• Objects with a 0 object type. These objects are usually 
user-defined images for special-purpose applications. They 
are named when a user requests a connection. Objects in 
this category are defined in the DECnet-VAX configuration 
database as TASK (see Section 3.9.1). The object type 
number for all of these objects is 0. 

• Nonzero objects. Nonzero objects are known objects that 
provide specific network services such as FAL (file access) 
or NML (network management). They may also be user- 
defined tasks; these objects should be for user-supplied 
known services. Object type numbers for all nonzero objects 
range from 1 to 255. The number serves as a standard 
addressing mechanism across a heterogeneous network. For 
a complete list of network objects, refer to the NCP section 
of the VAX/VMS Utilities Reference Volume. 

The following DIGITAL-supplied objects are defined inside 

NETACP, by default, in the configuration database. Note that 

MAIL and PHONE are specific to VAX/VMS. 

• File access listener (FAL). FAL is an image that provides 
authorized access to the file system of a DECnet node on 
behalf of processes executing on any node in the network. 
FAL communicates with the initiating node by means of the 
Data Access Protocol (DAP). 

• Network management listener (NML). NML is an image 
that provides services such as gathering and reporting 
information about network status, zeroing line and node 
counters, and loading a stand-alone system image to a 
remote node. 

• Event logger (EVL). EVL is an image that logs significant 
events (locally or remotely) for a given network component. 

• Loopback mirror (MIRROR). MIRROR is an image that is 
used for particular forms of loopback testing. 


2-39 



DECnet—VAX Components and Concepts 


• DECnet Test Receiver (DTR). DTR is a DECnet test 
program that is used with the DECnet Test Sender (DTS) to 
test logical links. The DTS/DTR Utility is described in the 
VAX/VMS Utilities Reference Volume. 

• MAIL. MAIL is an image that provides personal mail service 
for VAX/VMS nodes. 

• PHONE. PHONE is an image that allows you to have 
online "conversations" with users on VAX/VMS. 

• Host loader (HLD). HLD is an image that provides downline 
task-loading support for RSX-11S tasks. 

For every object that can be started by an inbound connection 
request, you must supply a command procedure unless either 
of the following conditions exists: 

• The object is one of the following DIGITAL-supplied 
command procedures: FAL, HLD, NML, EVL, DTR, MAIL, 
PHONE, MIRROR 

• The object is defined as an image, through specification of 
objectname.EXE as the object file name. 

Rules for establishing and identifying command files for objects 
are given in Chapter 3. 

You can also specify privileges a user must have in order 
to connect to the object, and provide default access control 
information to be used for inbound connections to the object 
when no access control is specified by the remote node. 
Additionally, you can assign default proxy login access controls 
for the object. Refer to Section 2.10 for a discussion of access 
control information used for logical link connections and a 
description of proxy login access control. 
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2 . 6.2 


Creating DECnet—VAX Network Server Processes 

On VAX/VMS, all DECnet objects run as processes. Unless a 
currently running process has declared itself to be a numbered 
network object or a named network object (with number 
0), NETACP must invoke a process to receive the connect 
request. When the logical link request comes in, a standard 
procedure called NETSERVER.COM is run, which in turn 
causes NETSERVER.EXE to be executed. This program works 
in concert with NETACP to invoke the proper program for the 
requested object. Then, when the logical link is disconnected, 
the "object" program (such as FAL) terminates, but the process 
is not deleted. Instead, control returns to the NETSERVER.EXE 
program, which asks NETACP for another incoming logical link 
request to process. This cycle continues until NETSERVER is 
deleted after a specified time limit. The default is 5 minutes. 

To use a different default time limit, specify the logical name 
NETSERVER$TIMEOUT, using an equivalence string in the 
standard VAX/VMS "delta time" format: 

dddd hh:mm:ss.cc 


The effect of NETSERVER is to reuse network server processes 
for more than one logical link request, eliminating the overhead 
of process creation for an often-used node. NETACP reuses a 
NETSERVER process only if the access control on the connect 
request matches that used to start the process originally. 

When NETACP creates a process to receive the connect request, 
the process runs like a batch job. The sequence is as follows: 

1 The process is logged in according to information found in 
the UAF. The key to this file is the username, which is part 
of the access control information. The process is successfully 
logged in only if the password from the access control 
string matches the password in the UAF record. (Refer to 
Section 2.10 for a discussion of DECnet access control.) 

2 DECnet-VAX automatically creates a log file in 
SYS$LOGIN:NETSERVER.LOG. Unlike the log file for a 
batch job, this log file is neither printed nor deleted. The 
log file is helpful for debugging your own network tasks. 

If NETSERVER.LOG cannot be created for any reason, the 
network job will continue running but will not produce any 
log file. 
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2.6.3 


3 The login command procedure indicated in the UAF for the 
process is executed. 

4 The process runs a command file to start the image that 
implements the DECnet object. The rules for locating this 
command file differ depending on whether or not the object 
has the number 0. 

Because NETSERVER.LOG files are not required for network 
server processes, you may explicitly inhibit all log files in your 
default DECnet account by setting the default directory for the 
account to a nonexistent directory. The effect of this action is to 
suppress all log files, while allowing network jobs to be run. 


Potential Causes of Network Process Failures 

If a logical link fails and the status information displayed is 
"network partner exited," this message indicates a problem in 
the remote network server process. To determine the details 
of the failure, consult the NETSERVER.LOG file at the remote 
node. Common reasons for failure are 

• Inability to log in due to failure to access the system login 
procedure, or the account login procedure or any files that it 
accesses. 

• Protection set on network procedures and images 
in SYS$SYSTEM, such as NETSERVER.COM or 
NETSERVER.EXE. 

• Attempted execution in your LOGIN.COM file of an 
interactive command that does not apply to network 
/batch jobs (for example, a SET TERMINAL/VT100 or SET 
TERMINAL/INQUIRE command). These commands should 
not be specified in your LOGIN.COM file unless they are 
preceded by IF F$MODE() .EQS. "INTERACTIVE". 

For example, in your LOGIN.COM file, use the following to 
prevent a logical link failure: 

$ IF F$MODE() .EQS. "INTERACTIVE" THEN - 
SET TERMINAL/VT100 

Any failure to create NETSERVER.LOG will cause a network 
job to continue running, but without a log file. 
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2.6.4 VAX PSI Objects 

The object component of VAX PSI contains records that identify 
the object, specify a command procedure that is initiated when 
the incoming call arrives, and specify account information for 
the incoming call. 

You must identify each VAX PSI object by a unique name. For 
each object, you must create a command procedure for starting 
the object that will be executed each time an incoming X.25 call 
to the object is received. Rules for establishing and identifying 
the command procedures are given in Chapter 3. For each 
object, you must also supply account information (consisting of 
a user name, password, and, optionally, an account name) to be 
used by incoming X.25 calls from remote DTEs. 


2.7 X.25 and X.29 Server Modules 

To handle calls coming in over a PSDN from remote DTEs 
and terminals, configure the X.25 and X.29 server modules, 
referred to as the X.25 and X.29 call handlers, as required. The 
X.25 server module handles incoming calls that originated at 
a remote DTE; the X.29 server module handles incoming calls 
that originated at a remote terminal. Your local DECnet-VAX 
node can receive X.25 and X.29 calls if it is configured as any of 
the following: 

• A DTE connected directly to a PSDN (to be a DTE, a 
DECnet-VAX node must have VAX PSI software installed) 

• A multihost connector node that forwards calls between 
a PSDN and host nodes on an Ethernet (to serve as a 
connector node, a DECnet-VAX node must be configured 
with VAX PSI software in multihost mode) 

• A host node on an Ethernet that uses a connector node to 
send and receive X.25 and X.29 calls (to be a host node, 

a DECnet-VAX node must be configured with VAX PSI 
Access software) 
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Destination of Calls from a Remote DTE 

The configuration database for the server modules defines 
the processes that are the destinations for calls, so that 
incoming calls from a PSDN can be directed to the appropriate 
destination. If your node is serving as a DTE connected directly 
to a PSDN or as a host node using an X.25 connector node, 
the destination is on the local node. If your node is serving as 
an X.25 connector node, the destination is on one of the host 
nodes using the connector node. 

The server database specifies the maximum number of circuits 
the server module may have; that is, the maximum number of 
incoming and outgoing calls that all destinations can handle. 

When establishing the server configuration database, you must 
identify each destination by a unique alphanumeric name. 

You must also name the object activated when a particular 
destination accepts an incoming call, and assign priorities to 
all destinations that could handle the same incoming call. 
Optionally, you can restrict the incoming calls a destination will 
handle to any or all of the following: 

• Calls to specified local DTE subaddresses 

• Calls from specified user groups (BCUGs and CUGs) 

• Calls from specified remote DTEs 

• Calls containing user data that matches a specified call value 
once a mask has been applied 

If your local node is serving as an X.25 connector node, you 
must identify in the X.25 server database the host node on 
which each destination is located. 

Chapter 3 describes how to use NCP commands to specify call 
handling parameters in the configuration database. 
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2.7.2 


Handling Incoming Calls at the Local DTE 

This section describes the process of handling incoming calls at 
the local DTE as it relates to network management. The VAX 
PSI X.25 Programmer's Guide describes the handling of incoming 
calls as it relates to programming PSI network tasks. 

Whenever a remote DTE attempts to communicate with your 
local DTE (that is, attempts to set up a virtual circuit), both 
the remote DTE and the local DTE provide information that 
identifies the user process to take the call. The process is 
the destination of the call. Remote DTE information passed 
with the call is optional; such information may include the 
remote DTE address, a local DTE subaddress, a closed user 
group (CUG) or bilateral closed user group (BCUG) name, and 
possibly a value in the user data field. VAX PSI at the local 
DTE uses this information, along with destination information 
defined in the configuration database at the local DTE for the 
server module and objects, to determine how to handle the 
incoming call. 

When an incoming call is received, VAX PSI constructs a 
network connect block (NCB) using the remote DTE address, 
and, if specified, the local DTE subaddress, the user group 
name, and user data. VAX PSI then attempts to match the 
information in these fields with the information specified for 
destinations in the configuration database. 

If only one match is made, VAX PSI associates the incoming 
call with the object specified in the configuration database 
for this destination. If more than one match is made, VAX 
PSI chooses the destination with the highest priority. Then it 
associates the incoming call with the object specified for this 
destination (see Section 2.6.4). 

The object names the task that is to run as a result of the 
incoming call. (A command procedure associated with the 
object is activated when the incoming call arrives; this user- 
written command procedure may activate a user program or 
an image.) Section 2.6 discusses objects and object parameters 
specified in the configuration database. 

VAX PSI rejects the incoming call if (1) no match is made, 
and (2) a last-chance destination has not been specified. A 
last-chance destination is a destination with an associated object 
that handles all incoming calls for which a match cannot be 
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found. The simplest last-chance destination is a destination 
that specifies the complete range of local DTE subaddresses, 
handles calls from all DTEs and all user groups, and ignores 
any incoming call-handling information in the user data field. 
It specifies no subaddress, no CUGs, no remote DTEs, and no 
local subaddresses. The last-chance destination must have the 
lowest priority of all the destinations. 


2.8 X.25 Access Module 

The X.25 access module provides a means for user processes 
on VAX/VMS host nodes to access remote nodes or terminals 
connected to a PSDN though a VAX/VMS node serving as 
a multihost connector node. Both the host node and the 
connector node must be on an Ethernet. The host node must 
be configured with VAX PSI Access software. The connector 
node must be configured with VAX PSI software in multihost 
mode. 

The X.25 access module identifies the connector node to which 
the local node is to be connected, the network the connector 
node can access, and, optionally, access control information. 
The DECnet-VAX host system with VAX PSI Access uses a 
DECnet link to connect to the connector node. VAX PSI Access 
software uses the link to transmit X.25/X.29 messages between 
the host and the connector node. 


2.9 Logging 

The network software logs significant events that occur during 
network operation. An event is defined as a network or system- 
specific occurrence for which the logging component maintains 
a record. A partial list of significant events includes 

• Circuit and node counter activity 

• Changes in circuit, line, and node states 

• Service requests (when a circuit or line is put in an automatic 
service state) 

• Passive loopback (when the executor is looping back test 
messages) 

• Routing performance and error counters (circuit, line, node, 
and data packet transmission) 
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• Data transmission performance and error counters (when 
errors in data transmission occur) 

• Lost event reporting (when some number of events are not 
logged) 


This information can be useful for maintaining the network 
because it can be recorded continuously by the event logger. 

As system manager, you are responsible for controlling certain 
aspects of event logging. In particular, you can control source- 
related parameters (actual events to be logged, the source for 
these events, and the location at which these events will be 
logged) and sink-related parameters (the name of the logging 
component at the local node and its operational state). 

For the most part, events are logged for the various DNA 
layers and for system-specific resources. Events are defined 
by class and type, in the format class.type. The class of an 
event identifies the layer or resource to which the event applies, 
and the type is the particular form of event within the class. 

For example, event 4.3 indicates oversized packet loss (type 
3) for the Routing layer (class 4). Event classes and types are 
summarized in the NCP section of the VAX/VMS Utilities 
Reference Volume . 

The logging component is the device or process that records 
logging events. You can specify any of the following logging 
components: 

• A logging console, which is a terminal or file that records 
events in user-readable form 

• A logging file, which records events in binary format 

• A logging monitor, which is a program supplied by the 
system or user that receives and processes events 

The sink name identifies the specific console, file, or monitor 
program to which events are to be logged. If you do not specify 
a sink name for the logging monitor, DECnet-VAX uses the 
Operator Communication (OPCOM) facility to display event 
messages on network operator terminals (terminals enabled 
through specification of the command REPLY/ENABLE=NET). 
The inherent flexibility of OPCOM and its ability to display 
messages at terminals being used for timesharing may make 
this alternative useful in situations where console logging is 
inappropriate. 
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The source of an event can be an area, node, module, circuit, or 
line. Events can be logged at either the local node or a remote 
node; this node is called the sink node. 

At the local node, you can control the operational state of the 
logging sink. You must turn logging on before events can be 
logged to the sink, and off before the logging parameters for the 
sink can be cleared from the database. Specify the hold state to 
queue events for a specific logging sink. 


2.10 Network Access Control 

DECnet-VAX regulates access to the network on various levels, 
including 

• Routing initialization passwords for links connecting the 
local node to remote nodes 

• System-level access control for inbound logical link 
connections that result in a process being created 

• Node-level access control for inbound and outbound logical 
links 

• Proxy login access control for individual accounts 

This section describes these levels of control as they relate to 
DECnet-VAX software operation, from the perspective of the 
system manager's need to establish control parameters through 
NCP. Use of specific NCP commands to accomplish access 
control is described in Chapter 3. 


2.10.1 Routing Initialization Passwords 

Whenever you turn on a circuit, your local node attempts 
to initialize with the DECnet software at the remote node 
connection for that circuit. As part of this initialization process, 
the remote node may require a password to complete the 
operation. The system manager can specify passwords when 
setting up the configuration database. 

In a Phase IV network, passwords are required when a Phase 
III node is initialized (see Section A.5.2.2), but are optional 
when a Phase IV node is initialized. Generally, passwords are 
used in initializing Phase IV nodes only when a system has 
dialup telephone lines used by the network. When a dialup 
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node seeks a dynamic connection over a terminal line, the 
dialup node must supply a password, but the node receiving 
the login request will not send a password to the dialup node. 


Figure 2-4 illustrates a routing initialization sequence for 
the network example. When the circuit is turned on, nodes 
BOSTON and TRNTO initialize. On the local node, BOSTON, 
DECnet-VAX software retrieves the transmit password for 
remote node TRNTO and sends it to TRNTO upon request. 

On node TRNTO, DECnet-VAX verifies this password with 
the receive password specified for remote node BOSTON in its 
configuration database. Once the passwords are verified, the 
link is operational; that is, the circuit state makes the transition 
from ON-STARTING to ON. 


Figure 2-4 Routing Initialization Passwords 


TRNTO 


NCP>SET LINE DMC-0 STATE ON 



ZK-548-81 


DECnet-VAX always solicits a receive password. However, if 
verification on the circuit is disabled, or if no receive password 
is specified in the database for the adjacent node, DECnet-VAX 
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will accept anything the adjacent node may send. The adjacent 
node is still required to send the verification message. 


2.10.2 System-Level Access Control 

DECnet-VAX provides system-level access control over logical 
link connections. The network user on the initiating node 
may explicitly supply an access control string to control which 
account is used on the remote node. If, however, the initiating 
node does not supply explicit access control information, 
DECnet optionally provides default access control when 
sending the request to the remote node. It also optionally 
provides default access control for incoming logical links if the 
initiating node has not supplied access control information. 


2.10.2.1 Setting Access Control Information for Outbound 
Connects 

The system manager can specify default access control 
information for outbound connections. This enables the local 
node to send outbound logical link requests with default 
access control information when that information is not 
explicitly provided. The remote node stores the access control 
information in its configuration database. The default access 
control information can include privileged and nonprivileged 
names and passwords to be used in connecting to a particular 
remote node. 

The system manager at a node can specify a list of privileges 
required for connection to a particular object, such as NML. 
When the local node requests connection to an object for which 
privileges have been specified, it sends the default privileged 
access control string to the remote node. If the system manager 
does not specify privileges for an object, such as FAL, the 
object is accessible to all users. When the local node requests 
connection to this object, it sends the nonprivileged access 
control string. 
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2.10.2.2 Sources of Access Control Information for Logical Link 
Connections 

Whenever a local DECnet node attempts to connect to a remote 
DECnet-VAX node by means of a logical link, system-level 
access control information is sent to the LOGINOUT image 
running in the context of a process on the remote node. Access 
control information can come from a number of sources: 

• The network user on the local node may explicitly supply 
an access control string. If this is the case, the remote node 
uses the access control information. 

• If the access control string is not explicitly supplied, the local 
node checks its object database against the privileges of the 
initiating process. If the object does not require privileges 
other than TMPMBX and NETMBX, the local node sends 
the default nonprivileged access control string from its node 
database to the remote node. 

• If the object requires privileges beyond TMPMBX and 
NETMBX, and the user process has the required privileges, 
the local node sends the default privileged access control 
string from its node database to the remote node. 

• If no access control string is supplied, the local node checks 
to see if proxy access is enabled at the participating nodes. If 
so, LOGINOUT checks the NETUAF.DAT file to determine 
whether a user should be logged in to a designated account 
rather than the default DECnet account. (Proxy login access 
control is described in Section 2.10.5.) 

• If none of the cases above is valid, the local node sends a 
"null" access control string. 

• When the remote node sees that no access control has been 
specified, it checks its object database. If the object database 
contains a default inbound access control string, the remote 
node uses that string. 

• If there is no default access control information in its object 
database, the remote node checks its node database for 
nonprivileged account information about the local node. 

If the information is there, the remote node uses the 
nonprivileged access control string. 
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Finally, if none of these sources supplies the information, the 
connection fails. 

Note: In DECnet-VAX usage, nonprivileged means NETMBX 
and TMPMBX privileges only. NETMBX is the minimal 
requirement for any network activity. Privileged means any 
privileges in addition to NETMBX or TMPMBX. 

Figure 2-5 illustrates the local node's access control options for 
inbound connection requests. 

Figure 2-5 Access Control for Inbound Connections 


OUTBOUND CONNECTION 
(from local node) 


INBOUND CONNECTION 
(from local node) 

from remote 
node 


LOGINOUT 
Uses it 



Regardless of the source, the remote node uses this information 
to determine whether a logical link can be established. The 
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way this validation process works is important for both the 
system manager and network users. This section discusses 
access control in terms of network management. Chapter 8 
discusses access control as it relates to user-level operations 
such as remote file access and task-to-task communication. 

Access control information is not used where the connection is 
to a program that has declared a name or object number and 
has started independently of DECnet. 

Access control information allows users on remote nodes 
to gain access to resources on the local node. The system 
manager must establish access control information in both 
the configuration database (for objects) and the UAF (for 
default network accounts) on the local node. Chapter 1 briefly 
describes the necessity for these default accounts. Chapter 5 
explains how to create a default DECnet account. 

Whenever NETACP on the local node receives an inbound 
logical link connection request, it creates a process and starts 
the LOGINOUT image, which verifies the user's access rights 
by checking the UAF. When VAX/VMS starts a user process 
as a result of an inbound connection request, the privileges 
with which that process runs are determined by the UAF record 
associated with the access control information passed in the 
connection message. This function is almost identical to the 
one that occurs whenever a local user starts a batch job; the 
difference is that the resulting LOG file will be neither printed 
nor deleted. Section 2.6 discusses this process in detail. 


2.10.2.3 Network Security and Passwords 

You can maintain password security in a network environment 
by protecting the network configuration files from unauthorized 
access. The most convenient way to do this is to require 
SYSPRV to access these files. NML must have access to 
network configuration files. NML on the remote node accesses 
these files when it sees the NCP commands that access 
the permanent database (DEFINE, PURGE, LIST, and SET 
"component" ALL). 

Once you have set access control (as described in the previous 
section), users must have the privileges necessary to perform 
the following operations: 

• To modify the volatile database, NML users must have 
OPER privilege. 
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2.10.2.4 


• To specify the permanent database (using the DEFINE 
command) or to update the volatile database with all 
parameters from the permanent database (using the SET 
"component" ALL command), the user must have OPER 
privilege and WRITE access to all permanent database files. 

• To remove specific parameters from the permanent database 
(using the PURGE command) or to reset or remove all 
parameters from the volatile database (using the CLEAR 
"component" ALL command), the user must have OPER 
privilege and write access to all permanent database files. 

To clear counters, the user must have OPER privilege. 

• To start the network, a user must have ACNT, CMKRNL, 
SYSNAM, and DETACH privileges. 

To make these safeguards operational, you should avoid 
assigning privileges beyond those normally used. In particular, 
you should not give the default privileged account SYSPRV. 
These default accounts should be in their own group to avoid 
extending group access to other directories on the local node. 
Sensitive files and directories may be protected against world 
access by requiring explicit access control to reach them. 


Inbound Default Access Control for Objects 

Another form of access control specific to network objects is 
default account information that is used by inbound connects 
from remote nodes that send no access control information. 
Because no access control information is supplied, the default 
information you specify for the object is used to allow the 
logical link connection to be made. One example of this is 
downline task loading. When SLD connects to HLD on the 
host node, default access control information specified for the 
HLD object is used. Refer to Chapter 4 for more information 
on downline task loading. 
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2.10.3 Access Control for Remote Command Execution 

If you are requesting that an NCP command be executed at a 
remote node, you can supply an explicit access control string 
or default to access control information in the configuration 
database. To supply an explicit access control string, use 
either the standard VAX/VMS node specification (node"user 
password account"::) or specify this access control information 
as parameters in the NCP command to be executed at a remote 
node. 


2.10.4 Node-Level Access Control 

As system manager, you can regulate two forms of node¬ 
level access control for incoming and outgoing logical links. 

One form involves specifying the ACCESS parameter for a 
particular node in your volatile database, and the other involves 
specifying the DEFAULT ACCESS parameter in your executor 
database. 

When an incoming or outgoing logical link connection is 
attempted, the executor node first checks its volatile database 
for the ACCESS entry for the target node. If the entry exists, 
the executor uses it. 

Because it might not be feasible to include an ACCESS entry 
for every node in a large network, DECnet-VAX provides the 
DEFAULT ACCESS alternative. If the logical link connection is 
attempted and there is no ACCESS entry for the remote node in 
the volatile database, the executor uses the DEFAULT ACCESS 
parameter value. 

Both commands accept the same set of parameter values, which 
are listed below. 
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INCOMING 

OUTGOING 

BOTH 

NONE 


Allows logical link connections from the remote 
node, but does not allow the local node to initiate 
connections to the remote node. 

Allows the local node to initiate connections to the 
remote node, but does not allow connections from 
the remote node. 

Allows incoming and outgoing logical link 
connections. This is the default. 

Does not allow incoming or outgoing logical link 
connections to this node. 


If no entry is specified for the ACCESS or DEFAULT ACCESS 
parameters, the DEFAULT ACCESS parameter defaults to 
BOTH. 

Only those users with OPER privilege can bypass this access 
protection. 

For each node, you can configure the privileged and 
nonprivileged accounts and passwords that constitute default 
access control information. This default access control 
information should match the system-level access control 
information established for the node (see Section 2.10.2). 

Another form of access control at the node level is the node 
checking that is performed before a system can dial in and form 
a dynamic asynchronous connection over a terminal line. For 
a description of security measures for dynamic asynchronous 
connections, see Section 2.10.6. 


2.10.5 Proxy Login Access Control 

Proxy login permits a user who is logged in at a remote node 
to be logged in automatically to a specific account at the local 
node, without having to supply any access control information. 
The remote user must have a proxy account on the local node 
that maps to a local user account. The remote user assumes the 
same file access rights as the local account and also receives 
the default privileges of the local account. The proxy login 
capability can be used to increase security, by minimizing 
the need to specify explicit access control strings in node 
specifications passed over the network or stored in command 
procedures. 


2-56 


July 1985 






DECnet—VAX Components and Concepts 


The procedure for establishing proxy accounts is summarized 
below, followed by a description of the means of controlling 
proxy login access over the network. 


2.10.5.1 Proxy Accounts 

Proxy accounts permit one or more users on a remote node 
to obtain access privileges on a node without having a private 
account on that node. The remote user can issue commands to 
access data that is accessible by the local account to which he 
has proxy access. 

The system manager controls the use of proxy accounts at the 
local node, using the Authorize Utility to create and modify the 
network user authorization file, NETUAF.DAT. NETUAF.DAT 
contains proxy login records, each of which maps a remote 
node name and user name (in the form NODE::USER) to 
the user name of a single local account. Each remote user 
can access only one local user account. For a summary 
description of proxy accounts and how to create them, see the 
Guide to VAX/VMS System Management and Daily Operations. 
The Authorize Utility is described in the VAX/VMS Utilities 
Reference Volume. 


2.10.5.2 Controlling Proxy Login Access 

If no access control string is supplied when the local node 
receives a request for initiation of an inbound connection, the 
local system checks to see if proxy access is enabled at the 
participating nodes. By default, both incoming and outgoing 
proxy login access is enabled for each node. If proxy access 
is enabled, LOGINOUT checks the NETUAF.DAT file to 
determine if the user should be logged in to a designated 
account rather than the default DECnet account. 

Proxy login access for the local node is controlled by the 
setting of the DEFAULT PROXY entry in the volatile database. 
DECnet-VAX has set this entry to permit proxy logins to be 
initiated by the local node or by the remote node; this is the 
recommended setting. The use of proxy logins can be restricted, 
however, through specification of the executor parameter 
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DEFAULT PROXY in the configuration database. The possible 
proxy access options for the local node are defined below. 


INCOMING 

OUTGOING 

BOTH 

NONE 


Allows proxy login access from the remote node to 
the local node. 

Allows the local node to initiate proxy login access 
to the remote node, but does not allow proxy login 
access from the remote node to the local node. 
Allows both incoming and outgoing proxy login 
access. This is the default and the recommended 
option. 

Does not allow incoming or outgoing proxy login 
access connections to the local node. 


Proxy login access to a specific network object is controlled 
by the value of the object parameter PROXY set in the 
configuration database. Defaults for each object are set in 
the database. Permitting proxy login access to an object is 
recommended only if the proxy access serves some useful 
purpose. For example, by default MAIL is set to prevent 
incoming proxy login, while FAL is set to allow both incoming 
and outgoing proxy login. 


Four options are available for the PROXY parameter for a 
network object: 


INCOMING 

OUTGOING 

BOTH 

NONE 


Allows proxy login to the object. 

Allows the object to initiate proxy login. 

Allows both incoming and outgoing proxy login 
access. This is the default option. 

Does not allow incoming or outgoing proxy login 
access. 


Note that there are advantages to disallowing incoming proxy 
access to an object (such as MAIL) that does not require it. 
Whenever possible, incoming connect requests are matched 
up with compatible existing NETSERVER processes, to avoid 
the overhead of unnecessary process creation. If a user on 
a remote node with outgoing proxy access sends a request 
to connect to an object with incoming proxy enabled on the 
local node, the connect request will only be matched with a 
NETSERVER process that was started by a previous request 
from the same user on the same node. This matching occurs 
because the proxy database is processed by LOGINOUT, not 
by NETACP. If the object disallows incoming proxy access, 
incoming connect requests will use default access control. 
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with a higher probability of being matched with an existing 
NETSERVER process. 


2.10.6 Security for DDCMP Point-to-Point Connections 

If a remote node requests a connection over a DDCMP point- 
to-point circuit, the local node can avoid revealing its routing 
initialization password, while requiring that the remote node 
supply its password. This security measure is used to protect 
the password of the local node when a dialup node initiates an 
asynchonous connection to the local node. 

For example, a user at a system with a terminal line (such as 
a Micro VMS system) can dial in to another system (such as 
a VAX/VMS system in a VAXcluster) and initiate a dynamic 
connection, causing the terminal lines to be converted to 
asynchronous DDCMP communications lines for the duration 
of the telephone call. To prevent attempts at access by callers 
at unauthorized nodes, certain checks have been included in 
the dynamic configuration process. The dialup node must be 
the type of node (router or end node) expected by the local 
VAX/VMS node. When the dialup node attempts to initialize, it 
must supply a routing initialization password to the local node, 
but the local node does not send its password to the dialup 
node. This preserves the security of the local node in case the 
dialup node is unauthorized. In addition, the connection has 
been configured to end automatically when the telephone is 
hung up. 
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Managing and Monitoring the 
Network 


This chapter explains how to use network management 
commands and parameters to configure, manage, and monitor 
network software. The management tools and components 
available to DECnet-VAX and VAX PSI users fall into 13 broad 
categories: 

• The configuration database 

• The Network Control Program (NCP) 

• The executor node and remote nodes 

• X.25 protocol modules 

• Circuits 

• Lines 

• Routing 

• Links 

• Objects 

• X.25 and X.29 server modules 

• X.25 access modules 

• Logging 

• Access control 


This chapter should provide enough information to build a 
network configuration database for your VAX/VMS operating 
system. It will also explain how to use most NCP commands 
at both the local node and remote nodes to modify parameters 
for the running network. See Chapter 5 for examples that 
use NCP commands to build databases for various network 
configurations. 
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DECnet-VAX and VAX PSI network components and operating 
concepts are described in Chapter 2. Reference information 
on the operation of the NCP utility program and the complete 
syntax of NCP commands appear in the NCP section in the 
VAX/VMS Utilities Reference Volume. 


3.1 The DECnet-VAX Configuration Database 

The DECnet-VAX configuration database contains files that 
provide information about the local node, remote nodes, local 
physical lines, local circuits, local logging, and local objects. 
Each DECnet node in the network has a network database that 
supplies component and parameter information of this kind. 

To ensure successful node-to-node communication, each node 
has a configuration database that consists of the following 
databases: 

• A node database with a record for each node, including the 
local node 

• A circuit database with a record for each circuit known to 
the local node 

• A line database with a record for each physical line known 
to the local node 

• A logging database with a record for each sink (logged 
events are sent to the sinks) 

In addition, NETACP provides a default object database with a 
record for each object known to the network, including objects 
(for example, FAL) that are defined when you bring up the 
local node. 

As system manager, you need to specify the nodes that can 
communicate with your node, the physical lines that connect 
the nodes, and the circuits associated with those lines. In some 
cases, this connection may include more than one line and 
circuit to the remote node. You also need to establish a variety 
of operational routing parameters for the local node to ensure 
proper network operation. 

To allow for communication between nodes, NETACP defines 
several network objects including NML, FAL, and TASK. 
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To provide network management flexibility, the DECnet-VAX 
configuration database consists of two distinct databases, one 
volatile and one permanent. In addition, if VAX PSI is included 
in the network, a VAX PSI configuration database, consisting of 
a volatile database and a permanent database, exists at the local 
DTE (see Section 3.1.3). 


3.1.1 The Volatile Database 

The volatile copy of the DECnet-VAX configuration database 
is memory resident; it allows you to control the running 
network without modifying the permanent database. NCP 
provides commands for setting, clearing, and showing network 
component parameters for the volatile database. NCP also 
permits you to copy current information about remote nodes 
from the node database of another node into your volatile 
database. 

You can change parameters in the volatile database while the 
system is running; these changes, however, will be in effect 
only until you modify them again or until the network is shut 
down. NETACP uses parameters specified only in the volatile 
database. 


3.1.2 The Permanent Database 

The permanent copy of the DECnet-VAX configuration 
database provides the initial values for the volatile database. 
You access the permanent database whenever you use the ALL 
parameter with the SET command, as, for example, when you 
bring up the network. In effect, the permanent database allows 
you to load network parameters into the volatile database when 
you boot the system. You can also change parameters in the 
permanent database. 

You can use NCP commands to define, purge, and display 
network component parameters in the permanent database. 

You can also use NCP to copy current remote node entries into 
your permanent node database from the database of another 
node to which you have access. 

You can optionally use the NETCONFIG.COM procedure to 
configure automatically the permanent database for your node 
(see Chapter 5). 
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3.1.3 VAX PSI Configuration Database 

The VAX PSI configuration database contains files that provide 
information concerning the local DTE, local lines, virtual 
circuits, local modules, and local objects. Each PSI DTE that is 
connected to a PSDN has a database that supplies component 
and parameter information of this kind. For successful DTE-to- 
DTE communication, each DTE has a minimum configuration 
database that consists of the following databases: 

• A circuit database with a record for each permanent virtual 
circuit (PVC), if PVCs are in use 

• An object database with a record for each object 

• A line database with a record for each physical line to the 
PSDN 

• A module database with records for the PSDN, the DTE(s), 
groups, and destinations 

The VAX PSI configuration is also stored in the DECnet-VAX 
configuration database. 

Just as with the DECnet-VAX configuration database, the VAX 
PSI configuration database consists of both a volatile and a 
permanent database. 

You can use NCP commands to configure the VAX PSI 
software at any time. STARTNET.COM sets the parameters 
in the volatile database every time you load the VAX PSI 
software (see Chapter 6). You can change parameters in the 
configuration database while VAX PSI is running. 


3.2 The Network Control Program 

The Network Control Program (NCP) is the vehicle for creating 
and modifying component parameters in the configuration 
database. In addition to the NCP command interface, DECnet- 
VAX users can write programs that communicate with NML 
through the Network Information and Control Exchange (NICE) 
protocol. For information concerning this interface, refer to the 
Network Management Functional Specification. 
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Most NCP commands allow you to modify either the volatile 
or the permanent database. NCP will access either database, 
depending on which keyword you use. For example, the 
following command accesses the permanent database to create 
or modify the address of a remote node: 

NCP> DEFINE NODE 14 NAME DENVER 

To change the parameter in the volatile database, issue the 
command 

NCP> SET NODE 14 NAME DENVER 

The following list distinguishes command keywords by function 
and the database that they access. 


Function 

Volatile 

Permanent 

Creating/modifying parameters 

SET 

DEFINE 

Clearing parameters 

CLEAR 

PURGE 

Displaying parameters 

SHOW 

LIST 


Because the commands to access the volatile and permanent 
databases are similar, this chapter uses volatile database 
commands in all examples. 

When configuring your network, you can use NCP either 
to build upon previously specified information or to change 
that information. Thus you do not have to delete all existing 
parameters and start over. For example, assume that you have 
identified a remote node address as 5. You can add node 
parameters for this record in the volatile database by using 
the SET NODE command. If you want to change the address 
of this node, you only need to specify a new address in the 
ADDRESS parameter of the SET NODE command. If you 
decide later that you want to remove any or all parameters for 
this node, then you could use the CLEAR NODE command. 
Commands to remove parameters exist for all network 
components. 

NCP commands operate on network components and their 
parameters. When issuing an NCP command, you must 
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provide the command keyword, the component, and one or 
more parameters and/or qualifiers, as shown in the example 
below: 

$ RUN SYS$SYSTEM:NCP 


NCP>SET 

NCP>SET 

NODE 11 

KNOWN LOGGING 

NAME BOSTON COUNTER TIMER 30 
STATE ON 

NCP>SET 

EXECUTOR 

STATE ON 


command component parameters 


Note that components consist of two types: singular (as with 
NODE BOSTON) and plural (as with KNOWN LOGGING). For 
example, you can display information about an individual node 
or all nodes (including the local node) in the network: 

NCP>SH0W NODE BOSTON COUNTERS 


NCP>SH0W KNOWN NODES COUNTERS 


Most NCP commands support both singular and plural 
component keywords. 

For a detailed description of NCP operation, the syntax of NCP 
commands, and examples of NCP command prompting, refer 
to the NCP section of the VAX/VMS Utilities Reference Volume. 


3.3 Node Commands 

To establish your VAX/VMS operating system as a node in the 
DECnet network, you must build the node database entries for 
the DECnet-VAX configuration database. This section describes 
identification of the executor node and remote nodes, and the 
node parameters required to build an operational network node 
database. It also discusses updating your node database by 
copying current information about remote nodes from another 
node to which you have access. 
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3.3.1 Executor Node Commands 

NCP allows you to manage the operation and configuration 
of both your local node and remote nodes in the network. 
Generally, the NCP commands you will issue at your local 
node will be executed on that node. Occasionally, however, 
you may want to issue commands from the local node to 
be executed on adjacent or remote nodes. To this end, NCP 
incorporates the concept of an executor node. The executor 
node is simply the node on which NCP functions are actually 
performed, which in most cases will be the local node. To 
perform NCP functions on remote nodes, NCP supports two 
commands: SET EXECUTOR NODE and TELL. 

Note: For command descriptions in this manual, the executor node 
on non-Ethernet circuits is assumed to be the local node 
(BOSTON) unless otherwise specified. On Ethernet circuits, 
the executor node is usually ROBIN. 


3.3.1.1 SET EXECUTOR NODE Command 

The SET EXECUTOR NODE command sets the executor to the 
node at which you want the commands to execute. One use of 
this feature is to display information about the configuration 
database of the remote node. Figure 3-1 illustrates this use of 
a remote executor node. 

As shown in Figure 3-1, you set the executor node by issuing 
the NCP command 

NCP>SET EXECUTOR NODE TRNTO 

NCP executes commands that you enter at your local 
node, BOSTON, at the remote executor node, TRNTO. The 
executor node interprets each command with its own network 
management software, and then performs the NCP function. 
Each command must be stated as if it were issued to NCP at 
the executor node. In this example, any information output 
that results from the execution of a command is displayed at 
node BOSTON. If the remote node is not running DECnet-VAX 
software, refer to the appropriate documentation for that node. 

To reset the executor to the local node, use the NCP command 

NCP>CLEAR EXECUTOR NODE 


The executor is always the local node when NCP is activated. 
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Figure 3—1 Remote Command Execution 


BANGOR 


DENVER 


NCP>SET EXECUTOR NODE TRNTO 
NCP> SHOW KNOWN LINES 



BOSTON 

(Local Node) 


NYC 

FROM BOSTON 

FROM TRNTO 


NCP> CLEAR EXECUTOR NODE 
NCP> 


FROM BOSTON 

ZK-1865-84 
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It is possible for several users at one node to set their executor 
to different nodes. 

When you issue a SET EXECUTOR NODE command, you 
can either include specific access control information or use 
the default access control information. The level of privilege 
allowed at the remote executor node depends on the access 
control information specified. (Section 3.13 describes the access 
control format.) 

Note: When you clear the executor node, NCP communicates with 
NML as a shared image in the same process. Hence, clearing 
the executor node resets the executor's privileges to those of 
your current process—that is, the process running NCP. 


3.3.1.2 TELL Prefix 

As an alternative to using the SET EXECUTOR NODE 
command, you may want to execute only a single command 
at a remote node or you may want to temporarily override 
the current executor. In either case you can use the TELL 
prefix with an NCP command. For example, if you issue the 
following command at node BOSTON, NCP displays line 
information for all physical lines connected to node TRNTO: 

NCP>TELL TRNTO SHOW KNOWN LINES 

Remote execution in this case applies only to the one command 
entered with the TELL prefix. Again, you can specify or default 
to access control information. 


3.3.2 Node Identification 

When configuring the network, you must identify in the 
executor configuration database the local node and all adjacent 
nodes connected to it by circuits. Identifying all nodes by name 
as well as address will permit you to reach any node by its 
name. This section describes node identification and discusses 
NCP parameters relevant to identifying nodes. 

Either the node address or the node name can serve as a node 
identifier (node-id). The node address is a decimal number 
assigned to the node in the configuration database. The address 
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must be unique within the network. The node address may 
include as a prefix the area number, a decimal integer indicating 
the area in which the node is grouped. In the node address, 
the area number and node number are separated by a period, 
in the following format: 

area-number.node-number 


For example, if node 3 is in area 7, its node address is 7.3. 

The area number must be unique within the network and the 
node number must be unique within the area. If you do not 
specify an area number, the area number of the executor node 
is used. The default area number for the executor is area 1. 

In multiple-area networks, it is recommended that you always 
specify the area number. 

A node name is an optional, unique alphanumeric string that 
contains up to six characters including at least one alphabetic 
character. It can be used interchangeably with the node address 
to identify a node. In the single-area network example in 
Chapter 1, the node name BOSTON and the node address 1.11 
identify the same node. 

When defining remote nodes in the volatile database, use 
the SET NODE command to specify node names and node 
addresses. The command below associates the node name 
TRNTO with the node whose address is 1.5. 

NCP>SET NODE 5 NAME TRNTO 

To specify a node address for the local node, use the SET 
EXECUTOR command, as in the following example: 

NCP>SET EXECUTOR ADDRESS 11 

Then, use the following command to specify a node name for 
the local node: 

NCP>SET NODE 11 NAME BOSTON 

By issuing these commands, you have established a remote 
node (TRNTO) whose address is 1.5 and the local node 
(BOSTON) whose address is 1.11. You can then build upon 
this information to establish parameters for the various nodes. 

Before a node can be accessed by name, you must specify a 
node name to be associated with a node address. 
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Once you set the executor node's address in the volatile 
database, you cannot change it unless you turn off and restart 
the network. However, you can change any other node's 
address at any time. For example: 

NCP>SET NODE TRNTO ADDRESS 6 
NCP>SET NODE TRNTO ADDRESS 8 


3.3.2.1 Maximum Address Parameter 

The MAXIMUM ADDRESS parameter sets the highest address 
that the local node will recognize. Setting this parameter 
allows you to group node addresses in a predefined range, 
which minimizes the size of internal data structures and control 
mechanisms for DECnet-VAX software. For example, the 
command below sets the highest remote node address at 17. 

NCP>SET EXECUTOR MAXIMUM ADDRESS 17 

It is recommended that when you set this parameter, you use 
the smallest number possible. The default value is 32. When 
you set the MAXIMUM ADDRESS parameter, you must also 
set the BUFFER SIZE parameter (see Section 3.3.4.1). 


3.3.2.2 Local Node Identification Parameter 

In addition to defining a node name and address for the 
local node, you can also specify a descriptive quoted string of 
alphanumeric characters. NCP will display this string whenever 
you issue the SHOW EXECUTOR or LIST EXECUTOR 
command. Use the IDENTIFICATION parameter with the 
SET EXECUTOR command to specify this optional information, 
as shown in the command below. 

NCP>SET EXECUTOR IDENTIFICATION "HOST SYSTEM" 

This command provides information that NCP displays 
whenever you use the SHOW EXECUTOR command to display 
executor node information, as in the following example: 

NCP>SHOW EXECUTOR CHARACTERISTICS 
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Node Volatile Characteristics as of 14-MAY-1984 11:27:07 

Executor node 

= 

1.11 (BOSTON) 

Identification 

= 

VMS HOST SYSTEM 

Management version 

= 

V4.0.0 

Incoming timer 

= 

45 

Outgoing timer 

= 

45 

NSP version 

= 

V4.0 

Maximum links 

= 

32 

Delay factor 

= 

80 

Delay weight 

= 

5 

Inactivity timer 

= 

60 

Retransmit factor 

= 

10 

Routing version 

= 

V2.0.0 

Type 

= 

routing IV 

Routing timer 

= 

600 

Subaddresses 

= 

1 

Broadcast routing timer 

= 

40 

Maximum address 

= 

255 

Maximum circuits 

= 

16 

Maximum cost 

= 

1022 

Maximum hops 

= 

15 

Maximum visits 

= 

63 

Max broadcast nonrouters 

s 

64 

Max broadcast routers 

= 

32 

Maximum buffers 

= 

100 

Buffer size 

= 

576 

Nonprivileged user id 

= 

NETNONPRIV 

Default access 

= 

incoming and outgoing 

Pipeline quota 

= 

1200 

Default proxy access 

= 

incoming and outgoing 


3.3.2.3 Using and Removing Node Names and Addresses 

Once you have specified a node name and address, you can use 
them interchangeably whenever you need to specify a node-id. 
The local DECnet-VAX software translates the node names into 
node addresses. In the single-area network example, the NCP 
commands below perform identical functions. 

NCP>SHOW NODE 5 CHARACTERISTICS 


NCP>SH0W NODE TRNTO CHARACTERISTICS 
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3.3.3 


To remove a remote node name from the volatile database, 
use the CLEAR NODE command. The following command 
removes the association between TRNTO and node 5: 

NCP>CLEAR NODE 5 NAME TRNTO 

To remove a remote node address from the volatile database, 
you must remove all parameters for the node. You can also 
remove addresses for all known nodes other than the local 
node, as in the following example: 

NCP>CLEAR NODE TRNTO ALL 


NCP>CLEAR KNOWN NODES ALL 

Once all parameters for a component are removed from the 
volatile database, the component is no longer recognized by the 
network. 

Note: To change the ADDRESS or BUFFER SIZE parameter for 
your node, you must first turn off the executor. Refer to 
Section 3.3.4.2 and Chapter 6 for information on changing 
the local node's operational state. 


Ethernet Addresses of Nodes 

Nodes on Ethernet lines are identified by unique Ethernet 
addresses. A message can be sent to one, several, or all 
nodes on an Ethernet line simultaneously, depending on the 
Ethernet address used. You do not normally have to specify 
the Ethernet address of an individual node in order to configure 
your network; the software at the node sets its own Ethernet 
address. You need to know the Ethernet address of a node 
for service functions (such as downline load, circuit loopback 
test, and configurator operations) but not for normal network 
operations. 
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3.3.3.1 Format of Ethernet Addresses 

An Ethernet address is 48 bits in length. Ethernet addresses 
are represented by six pairs of hexadecimal digits (6 bytes), 
separated by hyphens (for example, AA-01-23-45-67-FF). The 
bytes are displayed from left to right in the order in which they 
are transmitted; bits within each byte are transmitted from right 
to left. In the example, byte AA is transmitted first; byte FF is 
transmitted last. 

Xerox Corporation assigns a block of addresses to a producer of 
Ethernet interfaces upon application. Thus every manufacturer 
has a unique set of addresses to use. Normally, one address 
out of the assigned block of physical addresses is permanently 
associated with each interface (usually in a read-only memory). 
This address is known as the Ethernet hardware address of the 
interface. 

DIGITAL's interface to Ethernet (for example, the DEUNA or 
DEQNA controller) can set a different address to be used by 
the interface; this address is known as the Ethernet physical 
address. 

On power up of the node, the Ethernet physical address is set 
to the hardware address. When DECnet starts an Ethernet line 
(for example, UNA-0), it causes the DEUNA connected to that 
line to set its physical address to be in the range of DIGITAL 
Ethernet addresses. Specifically, the DEUNA constructs the 
Ethernet physical address by appending the 16-bit executor 
node address to a constant 32-bit number (AA-00-04-00) 
within the block of Ethernet addresses assigned to DIGITAL. 


r 


32 bits 




16 bits 



Constant within 
Ethernet block assigned 
to DIGITAL 


DECnet node 
address 


ZK-1215-82 


An example is a Phase IV routing node with DECnet address 
1.182 (decimal), which would be set to an Ethernet physical 
address of AA-00-04-00-B6-04. Because the DEUNA at the 
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node constructs its own physical address, users normally do not 
need to manipulate Ethernet addresses directly. 


Once the Ethernet physical address has been set to its new 
value, it is reset to its original hardware address value only 
under the following circumstances: 

• When a reset is issued to the DEUNA (for example, when 
the machine power is shut off) 

• When the state of the Ethernet line is set to OFF 


The Ethernet physical address of a node includes the number 
of the area in which the node resides. The area number is 
represented by the most significant 6 bits of the 16-bit DECnet 
node address, while the number of the node within the area 
is indicated by the least significant 10 bits of the node address 
(see Section 2.4.2). Therefore, changing the number of an area 
involves changing the Ethernet physical address of each node 
in that area. 

If an existing network is not divided into areas, the default area 
number 1 is stored in the DECnet node address of each node. 
Conversion of an existing network to a multiple-area network 
may involve modification of the area number in the executor 
node address. During the conversion process (described in 
Section A.4), the network is shut down, the executor node 
address in the configuration database is modified to include the 
new area number, and the network is turned back on. When 
DECnet is restarted, it causes the DEUNA at the executor node 
to reset its Ethernet physical address. 

However, if a non-DECnet communications application (such 
as a LAT terminal server) is connected to the same Ethernet as 
the executor node whose area number is being modified, the 
Ethernet address of the executor used by the application cannot 
be changed while the interface to the application remains 
allocated. Thus the application should be stopped when 
DECnet is shut down and restarted after DECnet is turned 
back on. 
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3.3.3.2 Determining the Ethernet Physical Address of a Node 

You can determine the Ethernet physical address of a node as 
follows: 

• Convert the Phase IV node address (in the format area- 
number.node-number, as described in Section 3.7.2) to its 
decimal equivalent, using the conversion algorithm 

(area-number * 1024) + node-number 

• Convert the decimal node address to its hexadecimal 
equivalent, reversing the order of the bytes to form the 
hexadecimal node address 

• Incorporate the hexadecimal node address in the format 
AA-00-04-00-hexnodeaddress 

For example, to determine the Ethernet physical address of a 
node whose node address is 63.171, calculate the following: 

(63 * 1024) ♦ 171 = 64683 decimal = FCAB hexadecimal 

Therefore the Ethernet physical address of the node is 

AA-00-04-00-AB-FC 

You can display the Ethernet physical address of a node by 
specifying the following command: 

NCP>SH0W EXECUTOR STATUS 

The resulting display contains the Ethernet physical address of 
the executor, as shown below. 

Physical address = AA-00-04-00-AB-FC 


3.3.3.3 Ethernet Physical and Multicast Addresses 

An Ethernet address can be a physical address of a single node 
or a multicast address, depending on the value of the low- 
order bit of the first byte of the address (this bit is transmitted 
first). The two types of node address are physical and multicast 
addresses. 

The Ethernet physical address is the unique address of a single 
node on any Ethernet (as described previously). The least 
significant bit of the first byte of an Ethernet physical address 
is 0. (For example, in physical address AA-00-04-00-FC-00, 
byte A A in binary is 1010 1010 and the value of the low-order 
bit is 0.) 


3-16 







Managing and Monitoring the Network 


The Ethernet multicast address is a multidestination address 
of one or more nodes on a given Ethernet. The least significant 
bit of the first byte of a multicast address is 1. (For example, in 
the multicast address AB-22-22-22-22-22, byte AB in binary is 
1010 1011 and the value of the low-order bit is 1.) A multicast 
address can be either of the following: 

• Multicast group address. An address assigned to any 
number of nodes; this address can be used to send a 
message to all nodes in the group in a single transmission. 
The number of different groups that can be formed equals 
the maximum number of multicast group addresses that can 
be assigned. 

• Broadcast address. A single multicast address (specifically, 
FF-FF-FF-FF-FF-FF) that can be used to transmit a message 
to all nodes on a given Ethernet. (Note that the broadcast 
address should be used only for messages to be acted upon 
by all nodes on the Ethernet, since all nodes must process 
them.) 


3.3.3.4 Values of DIGITAL Ethernet Physical and Multicast 

Addresses 

DIGITAL physical addresses are in the range AA-00-00- 
00-00-00 through AA-00-04-FF-FF-FF. Multicast addresses 
assigned for use in cross-company communications are shown 
below. 


Value 

Meaning 

FF-FF-FF-FF-FF-FF 

Broadcast 

CF-00-00-00-00-00 

Loopback assistance 


DIGITAL multicast addresses assigned to be received by other 
DIGITAL nodes on the same Ethernet are shown below. 
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3.3.4 


Value 

Meaning 

AB-00-00-01-00-00 

Dump/load assistance 

AB-00-00-02-00-00 

Remote console 

AB-00-00-03-00-00 

All Phase IV routers 

A B—00—00—04—00—00 

All Phase IV end nodes 

A B—00—00—05—00-00 

Reserved for future use 

through 


AB-00-03-FF-FF-FF 


AB-00-04-00-00-00 

For use by DIGITAL customers 

through 

for their own applications 

AB-00-04-FF-FF-FF 



DECnet always sets up the DEUNA at each node to receive 
messages sent to any address in the above list of DIGITAL 
multicast addresses. For information on sending messages to 
Ethernet multicast addresses, refer to the VAX/VMS I/O User's 
Reference Manual: Part II. 


Node Parameters 

To establish information used to control various aspects of the 
local node's operation within the network, you must specify 
the SET EXECUTOR command parameter ADDRESS, and 
you should specify MAXIMUM ADDRESS, BUFFER SIZE, 
and TYPE (you may be able to use a default value for the 
node type). In addition, you may wish to specify names, 
access control information, and node counter event logging 
information for any or all of the nodes. If a remote node 
can be loaded downline, you can specify a number of default 
parameters to be used locally to perform a downline load or 
upline dump operation. Table 3-1 lists all node parameters by 
function and indicates whether they apply to local or remote 
nodes or to both. 
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Table 3-1 Node Parameters and Their Function 


Parameters According to Function 

Local Remote 

Node Node 

Node identification 


ADDRESS node-address 

X X 

IDENTIFICATION id-string 

NAME node-name 

X 

X X 

Loop node identification 

CIRCUIT circuit-id 

X 

Counter timing for node counter 
logging events 

COUNTER TIMER seconds 

X X 

Local node state 


STATE 

X 

ON 


OFF 


RESTRICTED 


SHUT 


Access control 


ACCESS 

X X 

INCOMING 


OUTGOING 


BOTH 


NONE 


DEFAULT PROXY 

X 

INCOMING 


OUTGOING 


BOTH 


NONE 


NONPRIVILEGED 

X X 

ACCOUNT account 


PASSWORD password 

USER user-id 


PRIVILEGED 

X X 
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Table 3-1 (Cont.) Node Parameters and Their Function 


Local Remote 

Parameters According to Function Node Node 


ACCOUNT account 
PASSWORD password 
USER user-id 
Downline loading 

CPU cpu-type X 

DIAGNOSTIC FILE file-id X 

HARDWARE ADDRESS E-address X 

HOST node-id X 

LOAD FILE file-id X 

SECONDARY LOADER file-id X 

SERVICE CIRCUIT circuit-id X 

SERVICE DEVICE device-type X 

SERVICE PASSWORD hex-password X 

SOFTWARE IDENTIFICATION software-id X 

SOFTWARE TYPE type X 

TERTIARY LOADER file-id X 

Upline dumping 

DUMP ADDRESS number X 

DUMP COUNT number X 

DUMP FILE number X 

Routing initialization passwords 

RECEIVE PASSWORD password X 

TRANSMIT PASSWORD password X 

DDCMP circuit connection control 

INBOUND node-type X 

Data link control 

BUFFER SIZE number X 

MAXIMUM ADDRESS number X 

MAXIMUM BUFFERS number X 

MAXIMUM CIRCUITS number X 

SEGMENT BUFFER SIZE number X 
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Table 3-1 (Cont.) Node Parameters and Their Function 


Local 

Remote 

Parameters According to Function 

Node 

Node 

Logical link control 

DELAY FACTOR number 

X 


DELAY WEIGHT number 

X 


INACTIVITY TIMER seconds 

X 


INCOMING TIMER number 

X 


MAXIMUM LINKS number 

X 


OUTGOING TIMER seconds 

X 


PIPELINE QUOTA quota 

X 


RETRANSMIT FACTOR number 

X 


Routing control 

AREA MAXIMUM COST number 

X 


AREA MAXIMUM HOPS number 

X 


BROADCAST ROUTING TIMER seconds 

X 


MAXIMUM AREA number 

X 


MAXIMUM BROADCAST NONROUTERS number 

X 


MAXIMUM BROADCAST ROUTERS number 

X 


MAXIMUM COST number 

X 


MAXIMUM HOPS number 

X 


MAXIMUM VISITS number 

X 


ROUTING TIMER seconds 

X 


TYPE node-type 

X 


Incoming X.25 call control 

SUBADDRESSES range 

X 



You can specify parameters common to both the local node 
and remote nodes in one of two ways: use either the SET 
EXECUTOR or SET NODE command with the local node 
name or address to establish or modify parameters for the local 
node, or use the SET NODE command to establish or modify 
parameters for a remote node. 
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When using either the SET EXECUTOR or SET NODE 
command to establish or modify parameters for the local node, 
be sure to avoid using, in the same command, parameters listed 
only under the Local Node column and those listed under both 
the Local Node and Remote Node columns in Table 3-1. If you 
mix these parameters in a single command, you will receive an 
"invalid grouping error" message. For example, the following 
commands are valid: 

NCP>SET EXECUTOR ADDRESS 11 
NCP>SET NODE 11 NAME BOSTON 
NCP>SET NODE 15 SERVICE CIRCUIT DMC-1 - 
_ RECEIVE PASSWORD RSXNODE 

The first command specifies a node address for the local node. 
The second command specifies a node name for the node 
whose address is 1.11, which in this case is the local node. 

The third command specifies parameters for node 1.15. Note 
that this command contains parameters for both remote and 
adjacent nodes. The command below, however, is invalid 
because it mixes parameters. 

NCP>SET EXECUTOR ADDRESS 11 NAME BOSTON 

'/.NCP-I-NMLRSP, listener response - Invalid parameter grouping, Address 


The CLEAR NODE command clears parameters for either the 
local or remote nodes. The CLEAR EXECUTOR command 
clears local node parameters common to both local and remote 
nodes. You cannot clear the local node parameters BUFFER 
SIZE and STATE from the volatile database. You can, however, 
purge them from the permanent database with the PURGE 
EXECUTOR command. You can use this same command to 
remove local node parameters common to both local and 
remote nodes from the permanent database. 

Once the local node's state is set to ON, you cannot change the 
ADDRESS or BUFFER SIZE parameters for the local node. 
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3.3.4.1 


Data Link Control 

Several local node parameters regulate various aspects of 
physical line operation. Specify the size of NSP receive buffers 
and transmit buffers (segment buffers), the number of buffers 
used to transmit on all circuits, and the number of circuits 
that the local node can use as DECnet-VAX communication 
lines. NCP provides four parameters for this purpose: BUFFER 
SIZE, SEGMENT BUFFER SIZE, MAXIMUM BUFFERS, and 
MAXIMUM CIRCUITS. You should be careful to set the 
values for these parameters to a reasonable level, or system 
performance might suffer. The parameters all have reasonable 
default values. 

For X.25 data links, the node parameters do not directly affect 
physical line operation. 

Setting Buffer Sizes 

To specify the maximum size (in bytes) of NSP receive buffers, 
use the BUFFER SIZE parameter. For example, the following 
command sets the size of all receive buffers for the executor 
node to 576 bytes: 

NCP>SET EXECUTOR BUFFER SIZE 576 

This parameter also controls the maximum segment size of all 
NSP messages that the local node can receive and forward. 

The buffer size value that you select will be used for all lines. 
You cannot use the BUFFER SIZE parameter to select individual 
values for individual lines. You can, however, use the LINE 
BUFFER SIZE parameter in the SET LINE command to override 
the BUFFER SIZE value for specific logical links on a line, such 
as a particular Ethernet line (see Section 3.6.2.2). 

The default BUFFER SIZE value is equal to the SEGMENT 
BUFFER SIZE if specified; otherwise the default size is 576 
bytes. At a minimum, the buffer size must be 192 bytes. Refer 
to Chapter 5 and to the Network Services Functional Specification 
for more information in this area. 

You should consider a number of things when selecting the 
buffer size value. 

• These buffers require nonpaged memory pool. 
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• The SYSGEN parameter LRPSIZE should be set to the 
executor buffer size. In addition, the parameter LRPCOUNT 
should be at least as large as the total number of all receive 
buffers on all lines, plus twice the number of circuits. 

• Faster lines perform better with large buffers and large user 
messages that reduce the processor load. (The smaller the 
segments, the more messages are processed.) 

• Lines that are error prone (for example, telephone lines) 
should use small buffers (256 bytes) to reduce both the 
probability and the cost of retransmissions. 

The procedure for changing buffer sizes is described below. 

Note: It is strongly recommended that you use the same buffer 
size for all nodes in your network. Otherwise, nodes with 
smaller buffer sizes will drop packets when you attempt to 
route through them. 

Changing Buffer Sizes 

You can change the size of the buffers on all nodes without 
bringing down the entire network by performing a two- 
pass conversion process involving a second parameter, the 
SEGMENT BUFFER SIZE, as well as the BUFFER SIZE 
parameter. The conversion process requires only that you 
set the local node to the OFF state while changing the buffer 
size. 

The maximum size of the transmit buffer is specified in 
the SEGMENT BUFFER SIZE parameter. For example, the 
following command sets the maximum size of a transmit buffer 
to 576 bytes. 

NCP>SET EXECUTOR SEGMENT BUFFER SIZE 576 

The maximum size of the receive buffer is specified in the 
BUFFER SIZE parameter. The command below sets the 
maximum size of the receive buffer to 576 bytes. 

NCP>SET EXECUTOR BUFFER SIZE 576 

The SEGMENT BUFFER SIZE normally has the same value as 
the BUFFER SIZE, but may be set to less in order to perform 
the buffer size conversion process. The default value of the 
SEGMENT BUFFER SIZE is equal to the BUFFER SIZE if 
specified; otherwise the default size is 576 bytes. 
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The steps in the conversion depend on whether you are 
increasing or decreasing the size of the buffers. To increase 
the size of the buffers, perform the following conversion: 

1 In the first pass, reset the value of the BUFFER SIZE 
parameter at each node to the larger size, permitting each 
node to receive a larger message. 

2 In the second pass, reset the value of the SEGMENT 
BUFFER SIZE parameter at each node to the larger size, 
permitting each node to transmit a larger message. 

This two-pass process ensures that all nodes are able to receive 
and forward larger messages before any node is able to transmit 
a larger message. To decrease the size of the buffers, perform 
the following conversion: 

1 In the first pass, reset the value of the SEGMENT BUFFER 
SIZE parameter at each node to the smaller size, decreasing 
the size message that each node can transmit. 

2 In the second pass, reset the value of the BUFFER SIZE 
parameter at each node to the smaller size, decreasing the 
size message all nodes can receive. 

This process ensures that the size of messages that can be 
transmitted across the network is decreased before the size of 
the buffers that receive and forward messages is decreased. 

An example of the conversion process involves increasing 
the size of messages that can be transmitted and received 
over the network from 576 bytes to 1000 bytes. First, cause 
the following command to be executed at each node in the 
network: 

NCP>SET EXECUTOR BUFFER SIZE 1000 

Then cause the following command to be executed at each node 
in the network: 

NCP>SET EXECUTOR SEGMENT BUFFER SIZE 1000 

Each node will first be able to receive and forward 1000-byte 
messages, and then will be able to transmit them. 
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Maximum Number of Buffers 

To specify the maximum number of buffers for the transmit 
buffer pool, use the MAXIMUM BUFFERS parameter. The 
value that you assign determines the size of internal data 
structures for DECnet-VAX software. For example, this 
command sets the maximum number of buffers to 20: 

NCP>SET EXECUTOR MAXIMUM BUFFERS 20 


If you do not specify a value for this parameter, DECnet-VAX 
will provide a default value of 100. Thus you do not have 
to specify a value unless you want to limit the amount of 
nonpaged pool used by DECnet-VAX. For most operations, 
DECnet-VAX will allocate only as many buffers as it needs 
(even if you specify a greater number than the amount needed), 
and will not allocate more than the number of buffers that you 
specify. 

Maximum Number of Circuits 

To specify the maximum number of circuits that the user can 
identify in the volatile database, use the MAXIMUM CIRCUITS 
parameter. This value determines the size of internal data 
structures for DECnet-VAX software. For example, the 
following command establishes an upper limit of 3 circuits 
that the local node can use: 

NCP>SET EXECUTOR MAXIMUM CIRCUITS 3 

The default value for this parameter is 16. 

If the local node is connected to an Ethernet circuit, the value of 
the MAXIMUM CIRCUITS parameter cannot be changed while 
the executor and the Ethernet circuit are in the ON state. 
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3.3.4.2 


Operational State of the Local Node 

Use the STATE parameter in conjunction with the SET 
EXECUTOR command to exercise control of the operational 
state of the local node. There are four states associated with 
this parameter: 


OFF 

ON 

RESTRICTED 

SHUT 


Allows no new logical links to be created, 
terminates existing links, and stops route-through 
traffic. The NETACP process exits. 

Allows new logical links to be created. The ON 
state is the normal operational state allowing 
route-through traffic. 

Allows no new logical links from other nodes, 
yet does not inhibit route-through. 

Similar to RESTRICTED. However, once all logical 
links are terminated, the local node goes to the 
OFF state. 


Any network user with the OPER privilege may initiate or 
confirm a logical link connection even though the local node is 
in the RESTRICTED or SHUT state. Thus a system manager 
can use NCP and NML when the network is in either of these 
states. 


Chapter 6 discusses local node states in terms of controlling the 
operation of the local node, and thus the network as a whole. 

Note: You should never use the DEFINE EXECUTOR STATE OFF 
command for the permanent database because this command 
would cause the network to shut down immediately after 
being started. 


3.3.5 COPY KNOWN NODES Command 

You can update your node database by copying current 
information about remote nodes from the configuration 
database of any node to which you have access. Use the COPY 
KNOWN NODES command to copy the volatile or permanent 
node database entries from a remote node to either or both 
the volatile and permanent node databases on your node. If 
you specify the WITH CLEAR or WITH PURGE qualifier on 
the COPY command, the local node database to which the 
information is to be copied is cleared or purged before the 
information is copied. Only the executor node characteristics 
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and the name and address of the remote node are retained 
when the database is cleared or purged before a copy operation. 

The COPY KNOWN NODES command permits you to update 
your existing node database to reflect current data on remote 
nodes without having to shut down your node. If your network 
is large, the COPY command provides you with a means of 
keeping up with frequent changes in the composition of the 
network. For example, one node on an Ethernet may serve as 
the master, keeping in its node database current information on 
all remote nodes that can be accessed over the network. Then, 
as other nodes come up on the same Ethernet, they can obtain 
the latest version of the node database by copying it from the 
master node. 

If you did not specify any remote node entries when you 
configured your node, you can use the COPY command at 
any time to obtain the remote node entries that indicate the 
nodes to which you have access. If you want to copy the node 
database from a remote node which is not defined in your 
volatile database, you can specify the node's address in the 
COPY command; execution of the copy operation will cause the 
name and address of the node to be defined in your database. 

COPY KNOWN NODES cannot be used to copy a subset of a 
node database. 


3.3.5.1 COPY Command Parameters and Qualifiers 

The COPY KNOWN NODES command causes the names and 
addresses of remote nodes to be copied from a remote database 
to the local node database or databases you specify. The FROM 
node-id parameter in the COPY command specifies the remote 
node from which the node database information is to be copied. 
The following command indicates the remote node information 
is to be copied from the node database on node BANGOR: 

NCP>COPY KNOWN NODES FROM BANGOR 

You can include explicit access control information in the node- 
id field, or default to a proxy or DECnet account on the remote 
node, as appropriate. This command copies remote node data 
from node BOSTON on which user BROWN has an account 
with the password PASS 123: 

NCP>COPY KNOWN NODES FROM BOSTON"BROWN PASS123" 
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To indicate which node database at the remote node is to be 
copied, specify the USING VOLATILE or USING PERMANENT 
qualifier. For example, this command specifies that the 
permanent database at node BANGOR is to be copied: 

NCP>COPY KNOWN NODES FROM BANGOR USING PERMANENT 

If you do not specify the USING qualifier, the default value is 
USING VOLATILE. 

You can indicate the local node database to which the 
information is to be copied by specifying the TO qualifier. 

The local node database can be the volatile or permanent 
database, or both the volatile and permanent databases. In the 
following command, the volatile database at node BANGOR is 
to be copied to both the volatile and permanent databases at 
the local node: 

NCP>COPY KNOWN NODES FROM BANGOR TO BOTH 

If you do not specify the TO qualifier, the local database 
to which the remote node data is copied corresponds to 
the database on the remote node from which the data was 
copied (the volatile database is copied unless the USING 
PERMANENT qualifier is specified). The command below 
specifies that the volatile node database on node BANGOR will 
be copied to the volatile node database on your node: 

NCP>C0PY KNOWN NODES FROM BANGOR 

To clear or purge the local database before the copy operation 
is performed, specify the WITH CLEAR or WITH PURGE 
qualifier in the COPY command. The WITH CLEAR qualifier is 
appropriate if the local database is volatile; the WITH PURGE 
qualifier, if it is permanent. Specify either WITH CLEAR or 
WITH PURGE if both the volatile and permanent databases 
are to be cleared. (In practice, you can specify either value 
of the WITH qualifier to clear or purge either or both of the 
local databases.) The following command indicates that the 
permanent node database at the local node is to be purged 
before the remote node data from node BANGOR is copied to 
the local database: 

NCP>C0PY KNOWN NODES FROM BANGOR USING PERMANENT - 
TO PERMANENT WITH PURGE 
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3.3.5.2 Clearing or Purging the Local Node Database 

During a copy operation, if the volatile database is to be 
cleared, the entries for the executor node and any loop 
nodes are not cleared. If the permanent database is to be 
purged, however, the entry for the executor node is purged. 
Therefore, before the purge occurs, the copy operation 
causes the executor node characteristics to be saved: a LIST 
EXECUTOR CHARACTERISTICS command is executed and 
the executor characteristics are stored. After the purge is 
executed, the executor characteristics are reinserted in the local 
node database. 

In addition, the local node must retain the name and address of 
the remote node from which it is to copy the data. Before the 
clear or purge operation is performed, the name and address 
of the remote node are saved. This information is reinserted 
in the local node database after the clear or purge operation is 
completed. 

If an error occurs during execution of the LIST EXECUTOR 
CHARACTERISTICS command, the purge will be aborted. 
After the LIST operation has been performed, clearing or 
purging will continue even if errors are encountered. 

Clearing or purging the local database as part of a copy 
operation is recommended. If a clear or purge operation is 
not performed before the remote node data is copied, conflicts 
can occur between original node entries in the local database 
and node entries being copied from the remote node database. 
A node must be identified uniquely, by one name and one 
address. A conflict exists when the entries being copied on 
an existing database would cause one node address to be 
associated with two node names or two node addresses with 
one node name. When such a conflict occurs during the copy 
operation, the original node entry is not updated and an 
informational message is displayed. For example, if the local 
node database identified node A with address 3.1 and node B 
with address 3.3, an attempt to copy an entry that defines node 
A with address 3.3 would fail, and an informational message 
would be issued. 
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3.3.5.3 Copying the Node Database From a Remote Node 

Entering a COPY KNOWN NODES command causes the 
following steps to be performed: 

• If you indicate that the volatile node database at the 
remote node is to be copied (by specifying the USING 
VOLATILE qualifier in the COPY command), a SHOW 
KNOWN NODES command is executed at the remote node. 
If you indicate the permanent node database is to be copied 
(by specifying the USING PERMANENT qualifier), a LIST 
KNOWN NODES command is executed at the remote node. 

• The COPY operation extracts remote node names and 
addresses from data returned by the SHOW or LIST 
command. 

• For each node name and address extracted, a SET or 
DEFINE NODE command is executed on the appropriate 
local node database. If you indicate in the COPY command 
that the information is to be copied to the volatile database, 
the following command is executed for each entry: 

SET NODE ADDRESS address NAME name 

If you indicate the information goes to the permanent 
database, the following command is executed: 

DEFINE NODE ADDRESS address NAME name 

If you indicate the information goes to both local node 
databases, both SET NODE and DEFINE NODE commands 
are executed for each remote node entry. When the COPY 
operation receives the name and address of the local node, 
no SET or DEFINE command is performed. 

When the name and address of the remote node from which 
the data is being copied is returned, the entry will indicate that 
it is the executor node. When the remote node is defined in 
the local database, however, it will not be listed as an executor 
node. Loop node names listed in the node database at the 
remote node will not be defined in the local database. 

Once the COPY operation has begun defining the remote 
nodes, it continues trying to define the nodes despite any errors 
it may encounter. It will issue informational messages for errors 
in individual node entries. 


July 1985 


3-31 









Managing and Monitoring the Network 


3.3.5.4 Errors in Copying Remote Node Data 

During a copy operation, the following conditions can result in 

informational messages being displayed to the user 

• The executor node is not defined in the local database. 

• The remote node from which the data is to be copied is not 
defined or is defined only by address (and not by name) in 
the local database. 

• Remote node data is being copied into an existing node 
database and a conflict between node names and addresses 
prevents a node from being identified uniquely. 

• The volatile node database on the local node is being cleared 
before a copy operation and the executor characteristics are 
defined in the database. 

• The local volatile node database is being cleared before 
a copy operation and a loop node entry is defined in the 
database. 


3.3.5.5 Copying Remote Node Data After Purging the Local 

Node Database 

The following example illustrates the use of the COPY 
command to copy remote node entries from the permanent 
node database at node EAGLE to both the volatile and 
the permanent node databases at node WREN. The COPY 
command specifies that the local volatile node database is to be 
cleared and the local permanent node database is to be purged 
before the copy operation is performed. (In this example, only 
the node entries are indicated under the SHOW and LIST 
commands.) 

To determine the node entries in the volatile node database at 
the local node, enter the following command, which causes the 
node entries to be displayed: 

NCP>SHOW KNOWN NODES 

Executor node = 2.25 (WREN) 

State = on 

Node 

2.1 (A) 

2.2 (B) 

2.3 (C) 

2.9 (EAGLE) 
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To determine the node entries in the permanent node database 
at the local node, enter the following command: 

ncp>list known nodes 

Executor node = 2.25 (WREN) 

Remote node = 2.1 (A) 

Remote node =2.2 (B) 

Remote node = 2.3 (C) 

Remote node = 2.9 (EAGLE) 


You can determine the node entries in the permanent node 
database at node EAGLE by specifying this command, which 
causes the node entries to be displayed: 

ncp>tell eagle list known nodes 

Executor node = 2.9 (EAGLE) 

Remote node =2.1 (D) 

Remote node = 2.6 (E) 

Remote node =2.7 (F) 

Remote node = 2.8 (G) 

To perform the copy operation, enter the following COPY 
command. The messages generated during the copy operation 
will be displayed on your screen directly under the COPY 
command. These messages relate to clearing the volatile 
database and purging the permanent database. 

NCP>C0PY KNOWN NODES FROM EAGLE USING PERMANENT - 
_ TO BOTH WITH PURGE 

y t NCP-I-NMLRSP, listener response - Component in wrong state. Node 

y.NCP-I-NMLRSP, listener response - Unrecognized component. Node 
Loop node = 2.0 (++++) 

y.NCP-I-NMLRSP, listener response - Success 
Remote node =2.1 (A) 

%NCP-I-RECDELET, Database entry deleted 
y.NCP-I-NMLRSP, listener response - Success 
Remote node = 2.2 (B) 

%NCP-I -RECDELET, Database entry deleted 
y.NCP-I-NMLRSP, listener response - Success 
Remote node = 2.3 (C) 

%NCP-I-RECDELET, Database entry deleted 
'/.NCP-I-NMLRSP, listener response - Success 
Remote node = 2.9 (EAGLE) 

'/.NCP-1-RECDELET, Database entry deleted 
'/,NCP-I-NMLRSP, listener response - Success 
Executor node =2.25 (WREN) 
y,NCP-1-RECDELET, Database entry deleted 
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The first message under the COPY command indicates the 
executor node is not cleared from the volatile database because 
it is in the ON state. The second message is displayed because 
a loop node was encountered when the volatile node database 
was cleared. The loop node cannot be cleared using a CLEAR 
NODE node-id command because it is handled differently than 
other nodes. (For information on setting and clearing loop 
nodes, refer to Chapter 7.) The remaining messages indicate 
the node entries in the local permanent database are purged. 

To determine the final results of the copy operation, enter the 
SHOW KNOWN NODES command at your node to obtain the 
following display of node entries from your volatile database. 

NCP>SH0W KNOWN NODES 

Executor node =2.25 (WREN) 

State = on 

Node 

2.1 (D) 

2.6 (E) 

2.7 (F) 

2.8 (G) 

2.9 (EAGLE) 

Then enter the LIST KNOWN NODES command at your node 
to obtain the following list of node entries in your permanent 
node database. Note that the executor entry has been saved 
and restored after the purge. 

NCP>LIST KNOWN NODES 


Executor node 

= 2. 

25 (WREN) 

Remote 

node 

= 

2.1 

(D) 

Remote 

node 

= 

2.6 

(E) 

Remote 

node 

= 

2.7 

(F) 

Remote 

node 

= 

2.8 

(G) 

Remote 

node 

= 

2.9 

(EAGLE) 
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3.3.5.6 Copying Remote Node Data Without Purging the Local 

Database 

The following example illustrates the use of the COPY 
command to copy remote node entries from the permanent 
node database at node ROBIN to the permanent node database 
at node LARK without purging the local node database. In 
this example, node LARK has not defined the executor node or 
remote node ROBIN in its database; therefore, informational 
messages are displayed. Note that the copy operation is not 
performed for nodes A and C, because of a conflict between 
existing and updated addresses for these nodes. Informational 
messages are issued for the entries for nodes A and C. (In the 
example below, only the node entries resulting from the LIST 
commands are displayed.) 

To determine the node entries on the permanent node database 
at the local node, enter the following command, which causes 
the node entries to be displayed. 

NCP>LIST KNOWN NODES 

Remote node =2.1 (C) 

Remote node = 2.3 (A) 


You can determine the node entries in the permanent node 
database at remote node ROBIN (whose address is 2.20) by 
specifying the command below, which causes the node entries 
to be displayed. You can reach node ROBIN by specifying its 
address in the NCP command, even though the node is not 
listed by name in the local node database. 

NCP>TELL 2.20 LIST KNOWN NODES 

Executor node = 2.20 (ROBIN) 

Remote node = 2.1 (A) 

Remote node =2.2 (B) 

Remote node = 2.3 (C) 

To perform the copy operation, enter the following COPY 
command. The informational messages generated during 
the copy operation will be displayed on your screen directly 
under the COPY command. Note that remote node entries 
successfully copied to the local node database (such as node B) 
are not displayed under the COPY command. 
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3.3.6 


NCP>COPY KNOWN NODES FROM 2.20 USING PERMANENT 

7.NCP-I-NMLRSP, listener response - Unrecognized component, Node 
y,NCP-I-EXEABO , Executor characteristics not defined. 

7.NCP-I-NMLRSP, listener response - Unrecognized component, Node 
7.NCP-I-REMAB0, Remote node not defined. 

'/.NCP-I-NMLRSP, listener response - Invalid parameter value, Address 
Remote node =2.1 (C) 

NODE 2.1 NAME A 


y.NCP-I-NMLRSP, listener response - Invalid parameter value. Address 
Remote node = 2.3 (A) 


NODE 2.3 NAME C 


To determine the final results of the copy operation, enter the 
LIST KNOWN NODES command at your node to obtain the 
following display of node entries. 

ncp>list known nodes 

Remote node =2.1 (C) 

Remote node = 2.2 (B) 

Remote node = 2.3 (A) 

Remote node = 2.20 (ROBIN) 


Node Counters 

DECnet software automatically collects certain statistics for 
nodes in the network. These statistics are known as node 
counters. Such information may include the number of 
connects sent and received, the number of messages sent 
and received, and the number of packets lost. This information 
may be useful either alone or in conjunction with logging 
information to evaluate the performance of a given node. The 
network counter summary in the NCP section of the VAX/VMS 
Utilities Reference Volume describes the complete list of node 
counters. Refer to Section 2.9 for a discussion of logging. 

You can use NCP to regulate how often counters are logged 
and when they are zeroed. To do so, you can use the SET 
EXECUTOR or the SET NODE command with the COUNTER 
TIMER parameter. For example, the following command causes 
a node counter logging event to take place every 600 seconds 
for the local node: 

NCP>SET EXECUTOR COUNTER TIMER 600 
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The counters are then zeroed. Similarly, the following 
command specifies that counters for remote node TRNTO 
are to be logged at the local node every 600 seconds: 

NCP>SET NODE TRNTO COUNTER TIMER 600 

Note that these counters are maintained on the local node. 

To clear the COUNTER TIMER parameter, use the CLEAR 
EXECUTOR or CLEAR NODE command along with this 
parameter. 

You can display node counter statistics at any time while the 
network is running by using the SHOW NODE COUNTERS 
command. 

In addition, at any point when the network software is running, 
you can zero node counters for a given remote node, the 
local node, or for all known nodes. Use any of the following 
commands to zero node counters: 

NCP>ZER0 EXECUTOR COUNTERS 
NCP>ZER0 NODE BOSTON COUNTERS 
NCP>ZER0 KNOWN NODES COUNTERS 


3.4 X.25 Protocol Module Commands 

The X25-PROTOCOL module implements the X.25 level 3 
protocol, which controls the transmission of data packets. This 
module structures control and user data into packets, sequences 
these packets for transmission, and establishes, maintains, 
and clears X.25 virtual circuits. This module also associates 
local DTE addresses, and optionally group names, with this 
controlling information. 

Use separate SET MODULE X25-PROTOCOL commands to 
identify the PSDN and associate parameters with it, to specify 
a DTE, and to specify a group. Parameters that affect the 
operation of the X.25 protocol module specify data packet, call 
request, clear request, reset, and restart control information for 
the level 3 X.25 protocol. 
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3.4.1 Local DTE Identification 

Use the DTE qualifier to identify your local DTE(s) by DTE 
address. Each local DTE must have a unique address. See 
the appropriate PSI reference card for the formula of the DTE 
address on your network. The command below assigns an 
address to one local DTE. 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 ... 

A DTE is associated with a single line. VAX PSI currently 
supports two lines; therefore, you can configure two local DTEs. 

The following parameters can or must be associated with each 
DTE: operational state, line identification, channel identification, 
and maximum circuits. 


3.4.1.1 Operational State of DTE 

The STATE parameter specifies one of three operational states 
for each DTE. 

OFF Prevents use of the DTE and clears all existing virtual 
circuits. 

ON Allows normal use of the DTE. 

SHUT Prevents use of the DTE for any new activity, but allows 
existing virtual circuits to complete their operation. Once 
all circuits have been cleared, the DTE returns to the OFF 
state. 

The following command allows normal use of the DTE: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 STATE ON ... 

The ON and SHUT states have substates; for a complete list 
of states, substates, and their transitions, refer to the NCP 
section of the VAX/VMS Utilities Reference Volume. The STATE 
parameter is optional. If it is not specified, the state is set to 
OFF. 
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3.4.1.2 Line Identification 

The LINE parameter identifies the line associated with each 
DTE. Each DTE must have a unique line. Line identification 
takes the following format: 

dev-c[-u] 

dev Is a device name 

c Is a decimal number designating the device's hardware 
controller 

u Is a decimal unit or line number included if the device is a 
multiple unit line controller 

(Section 3.6.1 describes line identification.) 

Note that the unit number is optional for a DUP or DMF. The 
command below identifies the line KMX-0-0 associated with 
DTE 123789456: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 - 
_ LINE KMX-0-0 ... 

Use the SET LINE command to specify parameters for this line. 

The LINE parameter is mandatory when you specify a DTE for 
the first time. 


3.4.1.3 Channel Identification 

The CHANNELS parameter associates a set of logical channels 
to be used for outgoing calls with each DTE. Outgoing calls 
are all calls that originate from your DTE. Specify one or more 
logical channel numbers (LCNs) as a list. Separate multiple 
LCNs with hyphens to indicate ranges, and commas to indicate 
individual numbers. For example, the following command 
indicates that 20 is the first LCN, counting down from 20 to 10, 
then 3, and finally 9: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 - 
_ CHANNELS 20-10,3,9 ... 

Specify a value in the range 1 to 4095 for each number in the 
range. 


The CHANNELS parameter is mandatory when you specify 
a DTE for the first time. The values you specify are those 
supplied by the network authorities at subscription time. 
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3.4.1.4 


Maximum Circuits 


The MAXIMUM CIRCUITS parameter specifies the maximum 
number of circuits that each DTE can handle. For example, 
the following command specifies that the DTE 123789456 can 
handle a maximum of 200 circuits: 

NCP>SET MODULE X25-PR0T0C0L DTE 123789456 - 
_ MAXIMUM CIRCUITS 200... 

The MAXIMUM CIRCUITS parameter is optional and, by 
default, the maximum is 255. 

When you specify a DTE for the first time, this parameter 
indicates the size of the control area allocated from nonpaged 
pool. Thus, you cannot increase this value while the software is 
running. However, you can decrease the value and increase it 
again, provided that you do not specify a value larger than the 
original set. If this value is larger than required, nonpaged pool 
will be wasted. 



3.4.2 


Group Identification 


If you are a member of either a closed user group (CUG) 
or bilateral closed user group (BCUG), always identify the 
group with the GROUP qualifier. Each group should have a 
unique name, which is an id-string 2 to 16 characters long. The 
following commands show a series of group specifications: 

NCP>SET MODULE X25-PROTOCOL GROUP ESECUG ... 

NCP>SET MODULE X25-PROTOCOL GROUP DECCUG ... 

NCP>SET MODULE X25-PR0T0C0L GROUP BASINGSTOKE ... 


The local DTE, the group type, and the group number should 
be associated with each group. 
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3.4.2.1 Local DTE Identification 

Use the DTE parameter to specify the address of the DTE that 
is associated with the group name. For example: 

NCP>SET MODULE X25-PROTOCOL GROUP ESECUG DTE 123789456 ... 

The DTE parameter is mandatory when you specify a group for 
the first time. Note that once you set parameters for a group, 
you cannot change them except by clearing the group and 
setting it up again. 


3.4.2.2 Group Number 

Use the NUMBER parameter to specify the number that 
identifies your group. These numbers are allocated by the 
PSDN at subscription time. Specify a 2-digit number for a CUG 
and a 4-digit number for a BCUG. You can omit leading zeros. 
For example: 

NCP>SET MODULE X25-PR0T0C0L GROUP ESECUG NUMBER 12 ... 

The NUMBER parameter is mandatory when you specify a 
group for the first time. 


3.4.2.3 Group Type 

If you are a member of a BCUG, use the TYPE BILATERAL 
parameter to specify this group type. For example: 

NCP>SET MODULE X25-PR0T0C0L GROUP DECCUG TYPE BILATERAL ... 

If the group is a CUG, omit this parameter. 


3.4.3 Network Identification 

The system manager must always identify the PSDN to which 
the local DTE is connected. Use the NETWORK parameter 
to identify the network. For example, the command below 
indicates that your DTE is connected to the public packet 
switching data network in the United Kingdom. 

NCP>SET MODULE X25-PROTOCOL NETWORK PSS 
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3.4.4 


Always specify this parameter before specifying the parameters 
of the SET MODULE X25-PROTOCOL command listed below 
or any other commands. The parameter sets up defaults for the 
following network-specific parameters. 


Component Parameter 

MODULE X25—PROTOCOL CALL TIMER 

CLEAR TIMER 
DEFAULT DATA 
DEFAULT WINDOW 
MAXIMUM DATA 
MAXIMUM CLEARS 
MAXIMUM RESETS 
MAXIMUM RESTARTS 
MAXIMUM WINDOW 
RESET TIMER 
RESTART TIMER 

CIRCUIT MAXIMUM DATA 

MAXIMUM WINDOW 

LINE MAXIMUM BLOCK 

MAXIMUM RETRANSMITS 
MAXIMUM WINDOW 
RETRANSMIT TIMER 


See the appropriate PSI reference card for the network defaults 
of the above parameters. Note that the CIRCUIT values set up 
by the NETWORK parameter apply only to the PVC and DLM 
circuits. 


Data Packet Control 

The transmission of data packets over an X.25 virtual circuit is 
determined by the size of the packet and the window. 
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3.4.4.1 Packet Size 

The MAXIMUM DATA parameter specifies the maximum size 
of packets for all X.25 virtual circuits. The following command 
sets the maximum packet size to 128 bytes: 

NCP>SET MODULE X25-PR0T0C0L ... MAXIMUM DATA 128 ... 

The packet size must always be at least 5 bytes smaller than 
the maximum size of the frame on a line (see Section 3.6.5). 

If the value in the PSI$_NCB_PKTSIZE field of the network 
connect block (NCB) is greater than the value specified using 
the MAXIMUM DATA parameter, the MAXIMUM DATA value 
is used. 

The DEFAULT DATA parameter specifies a default packet size 
for all X.25 virtual circuits. For example, the command below 
sets the default packet size to 64 bytes: 

NCP>SET MODULE X25-PR0T0C0L ... DEFAULT DATA 64 ... 

The default packet size must always be less than or equal to the 
maximum packet size. If the PSI$_NCB_PKTSIZE field of the 
NCB is not specified, the default packet size is used. 

Values must be a power of 2 in the range 16 to 1024. 

The MAXIMUM DATA and DEFAULT DATA parameters 
are optional and take the network value by default. See the 
appropriate PSI reference card for the network values of these 
parameters. 


3.4.4.2 Window Size 

The MAXIMUM WINDOW parameter specifies the maximum 
window size for all X.25 virtual circuits. The value for this 
parameter will be the maximum number of packets for which 
outstanding acknowledgments are allowed. The command 
below sets the maximum window size to 3. 

NCP>SET MODULE X25-PR0T0C0L ... MAXIMUM WINDOW 3 ... 

If the value in the PSI$_NCB_WINSIZE field of the NCB 
is greater than the value specified using the MAXIMUM 
WINDOW parameter, the MAXIMUM WINDOW value is used. 
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The DEFAULT WINDOW parameter specifies a default window 
size for all X.25 virtual circuits. For example, the command 
below sets the default window size to 2. 

NCP>SET MODULE X25-PR0T0C0L ... DEFAULT WINDOW 2 ... 

The default window size must always be less than or equal to 
the maximum window size. If the PSI$_NCB_WINSIZE field 
of the NCB is not specified, the default window size is used. 

Specify values in the range 1 to 7. 

The MAXIMUM WINDOW and DEFAULT WINDOW 
parameters are optional and, by default, take the network 
value. See the appropriate PSI reference card for the network 
values of these parameters. 


3.4.5 Call Request Packet Control 

Use the CALL TIMER parameter to control call setup. This 
timer starts to run when a request to set up a virtual circuit is 
transmitted; if it terminates before a response has been received, 
the request will be cleared. In the command below, the request 
to set up a virtual circuit is cleared if no response has been 
received within 10 seconds. 

NCP>SET MODULE X25-PROTOCOL ... CALL TIMER 10 ... 

Specify a value in the range 1 to 255. 

The CALL TIMER parameter is optional and, by default, takes 
the network value. See the appropriate PSI reference card for 
the network value of this parameter. 


3.4.6 Clear Request Packet Control- 

Two parameters control transmission of clear request packets 
over SVCs: CLEAR TIMER and MAXIMUM CLEARS. 

Use the CLEAR TIMER parameter to control how often clear 
request packets are retransmitted if not acknowledged. The 
following command sets the retransmission frequency to 20 
seconds: 

NCP>SET MODULE X25-PROTOCOL ... CLEAR TIMER 20 ... 


3-44 





Managing and Monitoring the Network 


3.4.7 


Specify a value in the range 1 to 255. 

Use the MAXIMUM CLEARS parameter to specify the 
maximum number of times a clear request packet is 
retransmitted over the circuit. For example, the following 
command indicates that if a clear request is not acknowledged 
within 20 seconds, the request is retransmitted, and that this 
operation is to be performed a maximum of 8 times: 

NCP>SET MODULE X25-PROTOCOL ... CLEAR TIMER 20 - 
_ MAXIMUM CLEARS 8 ... 

An entry is placed in the error log, and the circuit is assumed to 
be cleared if the clear request is still not acknowledged by this 
time. 

Specify a value in the range 1 to 255. 

The CLEAR TIMER and MAXIMUM CLEARS parameters 
are optional and take the network value by default. See the 
appropriate PSI reference card for the network values of these 
parameters. 


Reset Control 

Two parameters control transmission of reset packets over SVCs 
and PVCs: RESET TIMER and MAXIMUM RESETS. 

Use the RESET TIMER parameter to control how often reset 
packets are retransmitted if not acknowledged. For example, 
the following command sets the retransmission frequency to 10 
seconds: 

NCP>SET MODULE X25-PR0T0C0L ... RESET TIMER 10 ... 

Specify a value in the range 1 to 255. 

Use the MAXIMUM RESETS parameter to specify the maximum 
number of times a reset is retransmitted to the DCE. The 
command below indicates that if a reset is not acknowledged 
within 10 seconds, the reset is retransmitted, and that this 
operation is to be performed a maximum of 8 times: 

NCP>SET MODULE X25-PR0T0C0L ... RESET TIMER 10 - 
_ MAXIMUM RESETS 8 ... 
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3.4.8 


An entry is placed in the system error log, and the circuit is 
cleared if the reset is still not acknowledged by this time. 

Specify a value in the range 1 to 255. 

The RESET TIMER and MAXIMUM RESETS parameters are 
optional and take the network value by default. See the 
appropriate PSI reference card for the network values of these 
parameters. 


Restart Control 

Two parameters control transmission of restart packets over 
the data link to the DCE: RESTART TIMER and MAXIMUM 
RESTARTS. Use the RESTART TIMER to control how often 
restart packets are retransmitted. For example, the command 
below sets the retransmission frequency to 20 seconds. 

NCP>SET MODULE X25-PR0T0C0L ... RESTART TIMER 20 ... 

Specify a value in the range 1 to 255. 

Use the MAXIMUM RESTARTS parameter to specify the 
maximum number of times a restart is retransmitted to the 
DCE. The command below specifies that a restart is to be 
retransmitted every 20 seconds, and that this operation is to be 
performed a maximum number of 10 times. 

NCP>SET MODULE X25-PR0T0C0L ... RESTART TIMER 20 - 
_ MAXIMUM RESTARTS 10 ... 

An entry is placed in the system error log if the restart is still 
not acknowledged by this time. 

Specify a value in the range 1 to 255. 

The RESTART TIMER and MAXIMUM RESTARTS parameters 
are optional and take the network value by default. See the 
appropriate PSI reference card for the network values of these 
parameters. 
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3.4.9 X.25 Protocol Module Counters 

VAX PSI automatically maintains certain statistics for the X25- 
PROTOCOL module in the network. These statistics are known 
as protocol module counters. They may include the number of 
bytes, data blocks, calls, and fast selects sent and received; the 
number of active channels; the number of resets sent, received, 
or initiated by the network; and the number of restarts. These 
statistics are useful in monitoring the activity of the component. 
A complete list of protocol module counters is given in the 
NCP section in the VAX/VMS Utilities Reference Volume. 


3.5 Circuit Commands 

The four classes of circuits that DECnet-VAX supports 
are DDCMP, Cl, Ethernet, and X.25 circuits. Using NCP 
commands, you must identify all DECnet circuits connected 
to the local node and all permanent virtual circuits connected 
to local DTEs, and specify parameters that affect the operation 
of the circuits. This section describes circuit identification and 
discusses using NCP commands to specify circuit parameters. 


3.5.1 Circuit Identification 

As with nodes, circuits must also have unique identifiers. 
DECnet circuits and X.25 circuits are not identified in the same 
way. 


3.5.1.1 DDCMP Circuit Identification 

For VAX/VMS, DDCMP circuit identification and line 
identification takes one of the following formats: 

dev-c 
dev-c-u 
dev-c.t 
dev-c-u.t 
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dev Is a device name. (Refer to the NCP section in the VAX/VMS 
Utilities Reference Volume for a complete list of mnemonic 
device names.) 

c Is a decimal number (0 or a positive integer) that designates 
the hardware controller for the device, 
u Is a decimal unit or circuit number (0 or a positive integer) 

that is included only if there is more than one unit associated 
with the controller. 

t Is a decimal number (0 or a positive integer) that identifies 
a tributary on a multipoint circuit. This is a logical tributary 
number, not to be confused with the tributary address that 
is used to poll the tributary. 

Note: Circuit devices that are similar in operation are referred to 
by the same mnemonic. 

DDCMP Point-to-Point Addressing 

The following command specifies a synchronous point-to-point 
circuit. The command identifies the DMC (or DMR) circuit 
device and controller number 0. 

NCP>SET CIRCUIT DMC-0 STATE ON 

The following command specifies an asynchronous point-to- 
point circuit. The command identifies the DZ11 asynchronous 
circuit device by the mnemonic TT, and specifies controller 
number 0 and unit number 0 (that is, TTAO). 

NCP>SET CIRCUIT TT-0-0 STATE ON 

Note that dynamic asynchronous DDCMP circuit names 
are supplied automatically when a dynamic connection is 
established. 

VAX/VMS maps network management circuit names to system- 
specific circuit names (for example, DMC-4 maps to XMEO). 
Network management circuit names provide network-wide 
circuit identification independent of individual operating system 
conventions. 
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DDCMP Multipoint Tributary Addressing 

The command below identifies the DMP circuit device, 
controller number 0, and logical tributary 1. 

NCP>SET CIRCUIT DMP-0.1 STATE ON 

Use the SET CIRCUIT command to turn on the DMP circuit 
device as a multipoint tributary device. 

DECnet-VAX software uses a form of circuit identification 
called a tributary address to poll a tributary for a specified 
circuit. Use the SET CIRCUIT command to establish the 
tributary address. For example, the command below specifies 
an address of 5 to tributary 1 on DMP controller 0. 

NCP>SET CIRCUIT DMP-0.1 TRIBUTARY 5 

Values in the range of 1 to 255 are valid for this parameter. 
The node at the controlling end of this multipoint circuit will 
use this address to poll this line. Correspondingly, you must 
set the tributary address on the remote node end of the circuit 
that will respond to a polling address of 5. For example: 

NCP>SET CIRCUIT DMP-1.0 TRIBUTARY 5 

The logical tributary number (0 in this case) is not to be 
confused with the tributary address. Refer to the description 
of logical tributary numbers in the circuit identification at the 
beginning of this section. 


3.5.1.2 Cl Node Addressing 

The TRIBUTARY parameter is also used to identify the Cl node 
on the other end of a Cl circuit. In the following example, the 
tributary address 1 identifies the Cl node on the other end of 
circuit CI-0.1: 

NCP>SET CIRCUIT CI-0.1 TRIBUTARY 1 

The tributary node address is the Cl port number of the remote 
Cl node, not the DECnet node address. 

Note that you must load the CNDRIVER before running 
DECnet over a Cl (see Section 2.2.3). 
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3.5.1.3 Ethernet Circuit Identification 

For VAX/VMS, Ethernet circuit identification takes the 

following format: 

dev-c 

dev Is a device name. (The device name for an Ethernet circuit 
is UNA for a VAX/VMS system and QNA for a MicroVMS 
system.) 

c Is a decimal number (0 or a positive integer) that designates 
the hardware controller for the device. 

For example, the command below identifies the circuit device 

UNA and the controller number 2 for an Ethernet circuit. 

NCP>SET CIRCUIT UNA-2 STATE ON 


3.5.1.4 X.25 Circuit Identification 

Use the SET CIRCUIT command to identify X.25 circuits. The 
text following the X25- prefix in the command string identifies 
all PVCs and DLM SVCs. The text is an alphanumeric string 
not more than 12 characters in length. The entire string, 
including the prefix X25-, should not be longer than 16 
characters. An example of this command is shown below. 

NCP>SET CIRCUIT X25-ANDIES ... 

Specify unique circuit identifiers for each additional X.25 circuit. 
For example: 

NCP>SET CIRCUIT X25-PVC0NE ... 

NCP>SET CIRCUIT X25-PVCTW0 ... 
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3.5.2 Circuit Parameters 

The configuration database contains circuit parameters for all 
circuits connected to the local node or DTE. Table 3-2 lists 
the types of circuits and the circuit parameters that apply to 
each type. The circuit parameters supply information used to 
control various aspects of a circuit's operation. Table 3-3 lists 
the circuit parameters by function. 


Table 3-2 Types of Circuits and Applicable Circuit Parameters 


Type of Circuit 

All circuits 


Circuits other than 
X.25 circuits 


Applicable Circuit Parameters 

COUNTER TIMER seconds 
STATE (ON 
< OFF 

(service 

COST cost 

HELLO TIMER seconds 



DDCMP circuits ACTIVE BASE base 

ACTIVE INCREMENT increment 
BABBLE TIMER milliseconds 
DEAD THRESHOLD count 
DYING BASE base 
DYING INCREMENT increment 
DYING THRESHOLD count 
INACTIVE BASE base 
INACTIVE INCREMENT increment 
INACTIVE THRESHOLD count 
MAXIMUM BUFFERS count 
MAXIMUM TRANSMITS count 
POLLING STATE polling-state 
SERVICE f ENABLED \ 

\ DISABLED f 

TRANSMIT TIMER milliseconds 
TRIBUTARY tributary-address 
VERIFICATION ( ENABLED ) 
l DISABLED \ 

| (inbound j 

Ethernet circuits MAXIMUM ROUTERS number 

ROUTER PRIORITY number 
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Table 3-2 (Cont.) Types of Circuits and Applicable Circuit 
Parameters 


Type of Circuit Applicable Circuit Parameters 


X.25 native PVCs 


X.25 DLM circuits 
(PVCs or SVCs) 


CHANNEL number 
DTE dte-address 
MAXIMUM DATA count 
MAXIMUM WINDOW count 
TYPE X25 

USAGE PERMANENT 


BLOCKING ( ENABLED ) 

\ DISABLED j 
CHANNEL number 
DTE dte-address 
MAXIMUM DATA count 
MAXIMUM RECALLS count 
MAXIMUM WINDOW count 


NUMBER dte-address 
OWNER EXECUTOR 
RECALL TIMER seconds 
TYPE X25 
USAGE 




{ INCOMING 
OUTGOING 
PERMANENT J 


> 


Table 3-3 Circuit Parameters and Their Function 


Parameter Function 

Indicates owner of circuit 
Identifies circuit by address 
Assigns circuit cost for 
routing purposes 

Sets counter timer for circuit 

counter event logging 

Sets circuit's operational state 


Parameters 
OWNER EXECUTOR 
TRIBUTARY tributary-address 
COST number 


COUNTER TIMER seconds 
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Table 3-3 (Cont.) Circuit Parameters and Their Function 


Parameter Function Parameters 


Controls DDCMP 
multipoint operation 


Sets timer to control Routing 
layer 

Determines whether service 
operations are allowed for 
circuit (initiated locally or 
remotely) 

Controls Routing layer 
initialization of adjacent node 

Limits number of routers 
permitted on Ethernet circuit 
Sets priority of router on 
Ethernet circuit for selection 
of designated router 
Associates logical channel 
number with X.25 PVC 
Associates local DTE 
with X.25 PVC 

Assigns remote DTE address used 
to establish a DLM outgoing SVC 
Defines circuit type; if circuit 
is not X.25, DDCMP is assumed 


ACTIVE BASE base 
DYING BASE base 
INACTIVE BASE base 
ACTIVE INCREMENT increment 
DYING INCREMENT increment 
INACTIVE INCREMENT increment 
DEAD THRESHOLD count 
DYING THRESHOLD count 
INACTIVE THRESHOLD count 
BABBLE TIMER milliseconds 
TRANSMIT TIMER milliseconds 
MAXIMUM BUFFERS count 
MAXIMUM TRANSMITS count 
POLLING STATE polling-state 
TRIBUTARY 

HELLO TIMER seconds 

SERVICE (ENABLED \ 

\ DISABLED) 


VERIFICATION (DISABLED) 

{enabled > 

(INBOUND } 
MAXIMUM ROUTERS number 


ROUTER PRIORITY number 


CHANNEL number 


DTE dte-address 


NUMBER dte-address 


TYPE X25 
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Table 3-3 (Cont.) Circuit Parameters and Their Function 

Parameter Function 

Parameters 

Controls data packet parameters 
for X.25 circuits 

MAXIMUM DATA count 


MAXIMUM WINDOW count 

Determines whether message 
blocking over DLM circuits 

BLOCKING (DISABLED \ 

\ ENABLED J 

occurs 


Controls retransmission of 

DLM outgoing SVCs 

MAXIMUM RECALLS count 

RECALL TIMER seconds 


Use the SET CIRCUIT command to set and modify these 
parameters. Use the CLEAR CIRCUIT command to reset them 
to their default values (if any) or remove them from the volatile 
database. The circuit must be off before you specify the ALL 
parameter in the CLEAR CIRCUIT command. The circuit must 
also be off if you wish to modify any parameters except COST, 
COUNTER TIMER, SERVICE, STATE, and VERIFICATION. 

Note that not all circuit devices support all parameters listed 
in the above tables. If a particular device does not support a 
parameter, an error message may be displayed. Refer to the 
VAX/VMS I/O User's Reference Manual: Part II for information 
on specific circuit devices. 


3.5.2.1 Operational State of the Circuit 

Just as you can control the operational state of the local node, 
you can also control the operational state of circuits connected 
to it. There are three circuit states: 

OFF Allows no traffic over a circuit. The circuit is 

unavailable for network activity. 

ON Allows traffic over the circuit. This is the normal 

operational state allowing for complete route-through 
and downline loading operations. 

SERVICE Restricts the circuit to service operations only. Only 
an Ethernet circuit will allow logical link activity or 
route through at the same time as service operations. 
Service operations include downline system loading, 
upline dumping, and loopback testing. 


Use the STATE parameter to specify the operational state of a 
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circuit. For example, this command allows normal traffic over 
circuit DMC-0: 

NCP>SET CIRCUIT DMC-0 STATE ON 

DECnet-VAX may automatically change the state of a DDCMP 
circuit for certain functions. For example, assume that you have 
set a DDCMP circuit to ON. Later, someone performs a circuit- 
level loopback test on that circuit without first setting the circuit 
state to SERVICE. Network management software automatically 
turns the circuit to the appropriate internal state (or substate) 
for the test. If the circuit state were displayed at that point, it 
would register as ON-LOOPING. When the circuit is in this 
state, it is in use for an active circuit loop test. This test is 
termed active because it was initiated on the local node. The 
local node enters the passive loopback state (ON-REFLECTING) 
whenever a remote node initiates a loopback test with the local 
node. When the test finishes, the circuit will return to the ON 
state. For a complete list of circuit states, substates, and their 
transitions, refer to the NCP section in the VAX/VMS Utilities 
Reference Volume. 

Several circuit substates have the prefix AUTO. These substates 
can occur when an adjacent node is or is about to be in an 
automatic downline loading or triggering stage. For example, if 
circuit DMC-2 is in the ON state and the local node (BOSTON) 
receives a request for a downline load on that circuit, the 
network software on the local node automatically sets the 
circuit to the ON-AUTOSERVICE state. 

Before performing service operations over a DDCMP circuit, 
you must enable that circuit. To do so, set the SERVICE 
parameter, which enables or disables service operations over 
a circuit. For example, the command below permits the circuit 
DMC-0 to be put in the SERVICE state, allowing service 
functions. 

NCP>SET CIRCUIT DMC-0 SERVICE ENABLED 

To disable a DDCMP circuit, set the SERVICE parameter 
to DISABLED, which allows you to restrict the operation of 
a circuit for network users. The default for the SERVICE 
| parameter is DISABLED. 
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3.5.2.2 Circuit Timers 

Two timers exist for controlling message transmissions and 
checking the status of adjacent nodes. The first is a hello timer, 
which defines the frequency of Routing layer Hello ("I'm still 
here") messages sent to the adjacent node on the circuit. The 
second is a "listen timer," which controls the maximum amount 
of time allowed to elapse before the Routing layer stops waiting 
for either a Hello message or a user message from the adjacent 
node on the circuit. You cannot set the listen timer with an 
NCP command; the value of the listen timer is always twice the 
value of the hello timer at the local node. 

To set the hello timer, use the command 

NCP>SET CIRCUIT DMP-0 HELLO TIMER 15 

This command sets a limit of 15 seconds between Hello 
messages from the executor node to the adjacent node on 
circuit DMP-0. The listen interval will be 30 seconds between 
messages from the node on circuit DMP-0 adjacent to the 
executor node. For the HELLO TIMER parameter, you must 
specify a value between 1 and 8191 seconds. The default value 
for the HELLO TIMER parameter is 15 seconds. 

The value of the HELLO TIMER parameter should be the same 
on all adjacent nodes over the same circuit. 

It is recommended that you accept the default value for 
the HELLO TIMER parameter, particularly if your node 
will communicate with nodes having versions of Network 
Management software earlier than Version 3.0. 


3.5.3 DDCMP Circuit Parameters 

Parameters unique to DDCMP circuits include the 
VERIFICATION parameter and parameters related to control of 
tributaries. 
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3.5.3.1 DDCMP Circuit Level Verification 

The VERIFICATION circuit parameter controls whether or 
not the local node will check the Routing layer passwords 
(RECEIVE PASSWORD and TRANSMIT PASSWORD) in the 
database entry for the remote node before it completes a node 
initialization request from that node. 

To turn on verification, issue the command 

NCP>SET CIRCUIT DMP-0 VERIFICATION ENABLED 

This command specifies that the Routing layer will perform 
initialization of the remote node connected to circuit DMP-0. 

To turn verification off, use the command 

NCP>SET CIRCUIT DMP-0 VERIFICATION DISABLED 

DISABLED is the default, which means that you need not 
specify a node in the configuration database to complete 
Routing layer initialization. To include a remote node in the 
configuration database, you must specify the NODE NAME and 
ADDRESS parameters; you can optionally specify the RECEIVE 
PASSWORD and TRANSMIT PASSWORD parameters. 

The following rules apply when a remote node submits a node 
initialization request to the local node: 

• Nodes not defined in the remote node database at the local 
node will not be able to initialize over a circuit that has 
verification enabled. 

• Nodes defined in the remote node database for which 
receive and transmit passwords are not specified, will be 
allowed to initialize whether or not verification is enabled 
on the circuit. 

• Nodes defined in the remote node database for which 
receive and transmit passwords are specified, will be allowed 
to initialize over a circuit with verification enabled provided 
the receive password in the local database matches the 
transmit password sent by the remote node. 

• Any node will be allowed to initialize over a circuit for 
which verification is disabled. 
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The VERIFICATION INBOUND parameter applies to any 
DDCMP point-to-point circuit. When VERIFICATION 
INBOUND is specified, the remote node submitting an 
initialization request to the local node must supply a transmit 
password that matches the receive password for that node in 
the local node database. The local node, however, will not 
send its initialization password to the requesting node. The 
VERIFICATION INBOUND parameter provides added security 
for the local node, which can verify the password of a node 
requesting a connection without revealing its own password. 

For example, to require that a remote node supply a password 
before it can initialize on circuit DMP-0 when the local node 
does not supply a password, specify the command 

NCP>SET CIRCUIT DMF-0 VERIFICATION INBOUND 

The VERIFICATION INBOUND parameter is supplied 
automatically for a dynamic asynchronous DDCMP circuit. 
When a dialup node requests a dynamic connection to the 
local node and the VERIFICATION INBOUND parameter is 
set for the circuit, you must specify the INBOUND parameter 
for the dialup node in the node database. If VERIFICATION 
INBOUND is not specified, the INBOUND parameter in the 
dialup node entry is ignored. 


3.5.3.2 DDCMP Tributary Control 

Several circuit parameters enable you to regulate and control 
tributaries. Some of these parameters apply to polling, others 
to timers. Note that you specify these circuit parameters on the 
control station, not on the tributary itself. 

Polling Over DDCMP Circuits 

To control the polling state of a tributary, use the DYING 
THRESHOLD, DEAD THRESHOLD, or INACTIVE 
THRESHOLD parameters. There are four polling states: 
ACTIVE, INACTIVE, DYING, and DEAD. These parameters 
determine the number of times the control station will poll 
the active, inactive, or dying tributary before changing its 
polling state. For example, the command below sets the polling 
threshold for circuit DMP-0.3. 

NCP>SET CIRCUIT DMP-0.3 DYING THRESHOLD 5 
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The control station will attempt to poll its tributary 5 times. If 
it gets receive timeouts for five consecutive polls, the control 
station changes the tributary's polling state from ACTIVE or 
INACTIVE to DYING. Values for the DYING THRESHOLD 
parameter range from 0 to 255 and the default is 2. The 
following command sets the polling threshold for circuit 
DMP-0.1: 

NCP>SET CIRCUIT DMP-0.1 INACTIVE THRESHOLD 12 

The control station will attempt to poll its active tributary 
12 times. If it receives only acknowledgments, but no data 
responses, the control station changes the active tributary's 
polling state to INACTIVE. The values for the INACTIVE 
THRESHOLD parameter range from 0 to 255 and the default 
is 8. 

You can lock a tributary into one of the four states by using 
the POLLING STATE parameter. Usually, the tributary's 
state is allowed to vary according to the multipoint polling 
algorithm. This variance occurs when this parameter is set to 
AUTOMATIC. Use this parameter to lock a tributary into the 
ACTIVE, INACTIVE, DYING, or DEAD state. For example, this 
command locks the tributary controlled by circuit DMP-0.1 into 
a DEAD state: 

NCP>SET CIRCUIT DMP-0.1 POLLING STATE DEAD 


The base priority of a tributary is the lowest value to which 
that tributary can be set after a poll. A control station polls 
tributaries with high priorities first. Note that a control station 
will not polltributaries with priorities below 128. To specify the 
base priority for a tributary, use the ACTIVE BASE, INACTIVE 
BASE, or DYING BASE parameters. After polling the tributary, 
the control station resets the base priority of the active, inactive, 
or dying tributary to this value. You can set a separate base 
value for each of the polling states, as shown in the following 
example: 

NCP>SET CIRCUIT DMP-1.2 ACTIVE BASE 225 

After a poll, the command above resets the base priority of the 
tributary on circuit DMP-1.2 to 225. The values for all BASE 
parameters range from 0 to 255. The defaults are ACTIVE, 255; 
INACTIVE, 0; and DYING, 0. 
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You can also increment the priority of a tributary each time 
the line-scheduling timer expires. If, for instance, the polls 
pass over a tributary with a low priority, you can raise the 
priority of that tributary by using the ACTIVE INCREMENT, 
INACTIVE INCREMENT, or DYING INCREMENT parameters. 
When the scheduling timer expires on an unpolled tributary, it 
increases the priority according to the value you set. You can 
set a separate increment value for each polling state, as shown 
in the following example: 

NCP>SET CIRCUIT DMP-2.2 INACTIVE INCREMENT 200 

This command adds 200 to the base priority of the tributary 
on circuit DMP-2.2. The increment values range from 0 to 
255. The defaults are ACTIVE, 0; INACTIVE, 64; and DYING, 
16. Note that if you set a 0 increment on a tributary with 
a base priority lower than 128, the tributary will never be 
polled. Active tributaries usually have a high base priority and, 
therefore, do not need a high increment value. 

The MAXIMUM BUFFERS and MAXIMUM TRANSMITS 
parameters give you further control over the tributary. 
MAXIMUM BUFFERS specifies the maximum number of buffers 
that a tributary can use from the common buffer pool. If you 
do not set this parameter explicitly, the default is 4. Values for 
this parameter can be either integers ranging from 1 to 254 or 
the keyword UNLIMITED. For example, this command sets an 
upper limit of 10 buffers that the tributary on this circuit can 
use from the common buffer pool: 

NCP>SET CIRCUIT DMP-0.2 MAXIMUM BUFFERS 10 


The MAXIMUM TRANSMITS parameter specifies the maximum 
number of data messages that the tributary can transmit in a 
single poll interval. Values range from 1 to 255; the default is 
4. For example, the command below sets an upper limit of two 
data message transmits from the tributary on this circuit. 

NCP>SET CIRCUIT DMP-0.2 MAXIMUM TRANSMITS 2 
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DDCMP Tributary Circuit Timers 

Two timers exist for controlling message retransmission at the 
DDCMP tributary circuit level. The babble timer controls the 
amount of time that a tributary or remote half-duplex station 
can transmit; the transmit timer sets the amount of time to 
delay between data message transmissions. To specify these 
timers, use these commands: 

NCP>SET CIRCUIT DMP-0.1 BABBLE TIMER 8000 
NCP>SET CIRCUIT DMP-0.1 TRANSMIT TIMER 4000 

The first command limits transmission time to 8 seconds (8000 
milliseconds) for the circuit's tributary. Values for the BABBLE 
TIMER parameter range from 1 to 65,535; the default is 6000 (6 
seconds). 

The second command sets a delay of 4 seconds (4000 
milliseconds) between each transmission from the tributary. 
Values for the TRANSMIT TIMER parameter range from 0 to 
65,535; the default is 0. 


Ethernet Circuit Parameters 

Parameters that Ethernet circuits have in common with other 
DECnet-VAX circuits are HELLO TIMER, COST, and STATE. 
Parameters unique to Ethernet circuits are ROUTER PRIORITY 
and MAXIMUM ROUTERS, which you can specify in the SET 
CIRCUIT command. 

If there are two or more routers on the same Ethernet, the 
one with the highest numerical priority (up to a maximum 
value of 127) is elected the designated router. The designated 
router provides message routing services for end nodes on the 
Ethernet (see Section 2.4.4.1). A designated router is selected 
even if there are currently no end nodes on the Ethernet. 

Note that routers are not required in order to route messages 
over the Ethernet on behalf of end nodes; Ethernet end nodes 
are capable of communicating directly. However, routers are 
required to route messages off of the Ethernet over other circuits 
such as DDCMP circuits. 

Use the SET CIRCUIT command to set the ROUTER PRIORITY 
value in the applicable circuit database at the executor node. 
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3.5.5 


For example, the following command assigns a router priority 
of 70 to local node ROBIN on circuit UNA-0: 

NCP>SET CIRCUIT UNA-0 ROUTER PRIORITY 70 

Each node on Ethernet circuit UNA-0 is assigned a router 
priority value in the range 0 through 127; the default value 
is 64. DECnet software compares the router priority values 
of the nodes and elects the router with the highest priority 
the designated router. If two or more nodes on the Ethernet 
have the same highest router priority value, the node with the 
highest node address is selected as designated router. To learn 
which router is the designated router, issue a SHOW ACTIVE 
CIRCUITS CHARACTERISTICS command. The following 
information will be displayed for circuit UNA-0: 

Designated router = 1.224 (ROBIN) 

Router priority = 70 

The recommended limit on the number of routers on an 
Ethernet circuit is 10, because of the control traffic overhead 
(composed of routing messages and hello messages) involved. 
The maximum number of routers allowed is 33. The 
MAXIMUM ROUTERS parameter specifies the maximum 
number of routers (other than the executor node) that the 
Routing layer is to allow on a particular Ethernet circuit. 

Use the SET CIRCUIT command to assign the MAXIMUM 
ROUTERS value for an Ethernet circuit. For example, the 
following command sets a maximum value of 4 to the number 
of routers (in addition to the executor node) that are permitted 
on circuit UNA-0: 

NCP>SET CIRCUIT UNA-0 MAXIMUM ROUTERS 4 

The default value is 33. 


Ethernet Configurator Module Commands 

Use the Ethernet configurator module to obtain a list of all 
systems on an Ethernet circuit or circuits. Each DIGITAL- 
supported node on an Ethernet circuit periodically transmits a 
system identification message to a multicast address to which 
the Ethernet configurator listens. The configurator uses these 
messages to build the configuration list. 
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Use NCP commands to access and control the configurator 
module. The configurator runs as a separate process, available 
to all users on the system. Once the configurator is started, it 
will continue to execute, maintaining and updating its database 
of information on active nodes until a user causes it to stop 
listening to system identification messages. 

If several users of a particular system issue SET MODULE 
CONFIGURATOR commands, they will all access the same 
configurator module. To determine whether the configurator 
module is already running, issue the following command: 

NCP>SHOW MODULE CONFIGURATOR KNOWN CIRCUITS 


3.5.5.1 Enabling Surveillance by the Ethernet Configurator 

To create or modify Ethernet configurator module parameters in 
the volatile database, use the SET MODULE CONFIGURATOR 
command. The SURVEILLANCE ENABLED parameter in this 
command causes the configurator module to begin listening to 
system identification messages transmitted by all systems on the 
circuit or circuits specified in the command. The configurator 
collects this information and constructs a list of systems and 
their capabilities in the volatile database. 


3.5.5.2 Obtaining a List of Systems on Ethernet Circuits 

To obtain information on the current configuration of nodes on 
Ethernet circuits, use the SHOW MODULE CONFIGURATOR 
command. This command permits you to access the 
configurator volatile database, which contains the following 
information for each system: 

• The Ethernet physical and hardware addresses of the system 

• The device connecting the system to the Ethernet 

• The maintenance version number of the system 

• A list of maintenance functions that can be performed by 
the node 

• The last time a system identification message was received 
from that system 
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The SHOW MODULE CONFIGURATOR command causes 
the configurator to display this information along with the 
amount of time surveillance has been enabled on the circuit. 
For example, for circuit UNA-0, the command 

NCP>SHOW MODULE CONFIGURATOR CIRCUIT UNA-0 STATUS 


will result in the following display: 


Module Configurator Volatile Status as of 22-MAR-1984 09:15:25L 


Circuit name 
Surveillance flag 
Elapsed time 
Physical address 
Time of last report 
Maintenance version 
Function list 
Hardware address 

Device type 

Circuit name 
Surveillance flag 
Elapsed time 
Physical address 
Time of last report 
Maintenance version 
Function list 
Hardware address 
Device type 


= UNA-0 
= enabled 
= 00:32:43 
= AA-00-04-00-A3-04 
= 22-Mar 9:14:8 
= V3.0.0 

= Loop. Primary loader 
= AA-00-03-00-00-07 

= UNA 

= UNA-0 
= enabled 
= 0:32:43 

= AA-00-04-00-A1-04 
= 22-Mar 9:11:29 
= V3.0.0 

= Loop, Primary loader 
= AA-00-03-00-00-57 
= UNA 


3.5.5.3 Disabling Surveillance by the Ethernet Configurator 

To cause the configurator to stop listening to system 
identification messages on specific Ethernet circuits, use the 
SURVEILLANCE DISABLED parameter of the SET MODULE 
CONFIGURATOR command. If you specify the KNOWN 
CIRCUITS parameter in this command, the configurator no 
longer listens to system identification messages being broadcast 
on any Ethernet circuit known to the local node. For example, 
this command causes the configurator to cease surveillance of 
all Ethernet circuits known to local node ROBIN: 

NCP>SET MODULE CONFIGURATOR KNOWN CIRCUITS - 
_ SURVEILLANCE DISABLED 

Once the configurator ceases surveillance of all Ethernet circuits 
it has been monitoring, the list of system information is deleted. 
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3.5.6 X.25 Circuit Parameters 

The circuit parameters described below apply to permanent 
virtual circuits (PVCs) used for X.25 operations. 


3.5.6.1 Parameters Common to X.25 Circuits 

The TYPE X25 and USAGE parameters are common to all X.25 
circuits. 

Use the TYPE parameter to specify a PVC as follows: 

NCP>SET CIRCUIT X25-ANDIES ... TYPE X25 ... 

Note that, by default, when the name of the circuit starts with 
"X25", for example, X25-ANDIES, the circuit type is X.25. The 
TYPE parameter is optional. 

Use the USAGE parameter to specify how a PVC is used as 
follows: 

NCP>SET CIRCUIT X25-ANDIES ... USAGE PERMANENT ... 

USAGE PERMANENT indicates that the circuit is permanently 
connected to a remote DTE and does not need to be switched 
dynamically. The USAGE parameter is mandatory for PVCs 
and takes no default. 


3.5.6.2 Permanent Virtual Circuit Parameters 

When PVCs are first specified, the CHANNEL and DTE 
parameters are mandatory. 

The CHANNEL parameter is used to associate a logical channel 
number with each PVC. This number is allocated to you by the 
PSN at subscription time and will be in the range 1 to 4095. 
Each PVC different from those previously specified for outgoing 
calls in the SET MODULE X25-PROTOCOL command must 
have a unique channel number. The command below illustrates 
the use of this CHANNEL parameter. 

NCP>SET CIRCUIT X25-ANDIES ... CHANNEL 3 ... 

The DTE parameter is used to associate the local DTE address 
with each PVC. The command below illustrates the use of the 
DTE parameter. 

NCP>SET CIRCUIT X25-ANDIES ... DTE 123789456 ... 
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The DTE address is a decimal integer of 1 to 15 digits and must 
be specified previously in a SET MODULE X25-PROTOCOL 
command. 


3.5.6.3 Data Packet Control 

Two parameters control the transmission of data packets over 
the PVC: MAXIMUM DATA and MAXIMUM WINDOW. 

The MAXIMUM DATA parameter specifies the maximum size 
of the packet for a particular circuit. For example, the following 
command sets the maximum size of the packet to 128 bytes for 
the circuit ANDIES: 

NCP>SET CIRCUIT X25-ANDIES ... MAXIMUM DATA 128 ... 

The maximum packet size must always be at least 5 bytes 
smaller than the maximum size of the frame on a line (see 
Section 3.6.5.1). Specify a value that is a power of 2 in the 
range 16 to 4096 bytes. 

The MAXIMUM DATA parameter is optional and, by default, 
takes the network value. See the appropriate PSI reference card 
for the network value of this parameter. 

The MAXIMUM WINDOW parameter specifies the window size 
for a particular PVC. For example, the command that follows 
sets the window size to 2 for the circuit X25-ANDIES: 

NCP>SET CIRCUIT X25-ANDIES ... MAXIMUM WINDOW 2 ... 

Specify a value in the range 1 to 127. 

The MAXIMUM WINDOW parameter is optional and, by 
default, takes the network value. See the appropriate PSI 
reference card for the network value of this parameter. 
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3.5.7 DLM Circuit Parameters 

A data link mapping (DLM) circuit allows an X.25 virtual 
circuit to be used as a DECnet data link in communicating with 
other DECnet nodes over a PSDN. Several circuit parameters 
are specific to the operation of DLM circuits: the OWNER 
EXECUTOR parameter, the remote DTE address used by 
DECnet to establish a DLM outgoing switched virtual circuit, 
two parameters to regulate recalls for DLM outgoing SVCs, and 
the usage of a DLM circuit. 

Parameters that DLM circuits have in common with other 
X.25 circuits are CHANNEL, DTE, MAXIMUM DATA, and 
MAXIMUM WINDOW. 


3.5.7.1 DLM Circuit Owner 

The OWNER EXECUTOR parameter is used to indicate that the 
Routing layer has exclusive rights to use the circuit. To specify 
that the circuit X25-DLMOUT should be used as a DLM circuit, 
use the following command: 

NCP>SET CIRCUIT X25-DLM0UT OWNER EXECUTOR 

The OWNER EXECUTOR parameter is required for a DLM 
circuit. 


3.5.7.2 Remote DTE Addresses 

To establish an SVC with a remote DTE, DECnet software 
requires the address of the remote DTE. Use the NUMBER 
parameter in the SET CIRCUIT command to specify the remote 
DTE address for incoming or outgoing DLM SVCs. 

For outgoing calls, the Routing layer uses this address (and the 
subaddresses required at the remote DTE) to call on the circuit. 
For example: 

NCP>SET CIRCUIT X25-DLM0UT NUMBER 3119123456781 

Outgoing calls on circuit X25-DLMOUT use the DTE 
311912345678 and a subaddress of 1 to establish an SVC 
with a remote DTE associated with this address. 
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For incoming calls, the NUMBER parameter is used to force 
them to a particular circuit on the basis of the remote DTE 
address. If a NUMBER parameter is specified for each incoming 
DLM circuit at the local DTE, an incoming call from a remote 
DTE will be rejected if its address does not match the number 
specified for any incoming circuit. If any incoming circuit does 
not have a number specified, then the circuit can handle calls 
from any DTE. The NUMBER parameter can also be used with 
an incoming circuit to specify additional routing parameters for 
a selected DTE. For example: 

NCP>SET CIRCUIT X25-INC USAGE INCOMING - 
_ NUMBER 3119123456781 COST 15 

Circuit X25-INC will receive calls only from the remote DTE 
with the DTE 311912345678 and subaddress 1. In this example, 
a cost of 15 is assigned to the DLM connection to remote 
DTE 311912345678 to reflect a higher routing cost for this 
configuration. 


3.5.7.3 Recalls for DLM Circuits 

If previous attempts to establish a DLM SVC have been 
unsuccessful, DECnet-VAX attempts to recall a number. The 
frequency of recalls and the maximum number of recalls 
DECnet attempts can be set with two parameters. The RECALL 
TIMER parameter sets the interval that DECnet should wait 
before attempting to place a call to establish an SVC. The 
MAXIMUM RECALLS parameter specifies the maximum 
number of times DECnet should attempt to place a call to 
establish an SVC. The command below will cause DECnet- 
VAX to place a call every 10 seconds for a maximum of 10 
times to establish an SVC for circuit X25-DLMOUT. 

NCP>SET CIRCUIT X25-DLM0UT RECALL TIMER 10 - 
_ MAXIMUM RECALLS 10 

The default value for the RECALL TIMER parameter is 3 
seconds. Unless you specify a value for the MAXIMUM 
RECALLS parameter, DECnet-VAX places no limit on the 
number of recalls attempted. If an attempt to make an outgoing 
call causes the system to exceed the MAXIMUM RECALLS 
parameter, the circuit is placed in the OFF state, and the 
following command is required before the outgoing call can be 
attempted again: 

NCP>SET CIRCUIT X25-DLM0UT STATE ON 
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3.5.7.4 DLM Circuit Usage 

DLM circuits operate according to the usage you define for 
them in the volatile database. DLM SVCs may be used either 
for outgoing or incoming calls. The usage of DLM PVCs is 
PERMANENT; that is, the circuit is permanently connected to 
a remote DTE, and does not need to be switched dynamically. 
The USAGE parameter specifies how DLM circuits are to be 
used, as in the following example: 

NCP>SET CIRCUIT X25-DLM0UT USAGE OUTGOING ... 


3.5.7.5 Executor Node Subaddresses 

When you are configuring the network, you can define a range 
of subaddresses that the DECnet Routing layer will accept 
as incoming DLM calls. VAX PSI will route all incoming 
calls within the specified subaddress range to the Routing 
layer, to be handled as DLM circuits. You are responsible 
for ensuring that the subaddress specified in the outgoing 
DLM NUMBER parameter (see Section 3.5.7.2) matches the 
range of subaddresses on the incoming side, as specified 
in the EXECUTOR SUBADDRESSES parameter of the SET 
EXECUTOR command. 

When the Routing layer receives an incoming call from a DTE, 
it scans the incoming DLM circuits to find the address of the 
DTE sending the call that matches the remote DTE address 
specified for the circuit (in the NUMBER parameter of the SET 
CIRCUIT command). If an incoming circuit does not have the 
NUMBER parameter specified, that circuit is selected to accept 
any incoming call that has not yet been matched to a particular 
circuit. If all incoming circuits have the NUMBER parameter 
specified and a call is received from a DTE whose address does 
not match any circuit, that call is rejected. 

Use the SUB ADDRESSES parameter in the SET EXECUTOR 
command to specify executor subaddresses (Section 3.3 
describes the SET EXECUTOR command). For example, use 
the SET EXECUTOR command to modify subaddresses in the 
volatile database: 

NCP>SET EXECUTOR SUBADDRESSES 42 
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The command above indicates that the Routing layer handles 
only incoming X.25 calls that specify local DTE subaddress 42. 
All other calls are handled by VAX PSI. A subaddress may 
consist of a range. For example, the command below indicates 
that the Routing layer all incoming X.25 calls that specify a 
local DTE subaddress in the range of 42 to 50: 

NCP>SET EXECUTOR SUBADDRESSES 42-50 

When specifying a subaddress range, use an integer in the 
range of 0 to 9999. Separate two subaddresses with a hyphen 
to indicate a range, and be sure the second subaddress is always 
greater than the first. 


3.5.7.6 Setting Up a DLM Circuit 

The following example illustrates how to set up a DLM circuit 
between DECnet node A (DTE address 123) and DECnet node 
B (DTE address 456), which are to communicate over a PSDN. 

On node A, the following command is used to specify the 
outgoing DLM circuit in the volatile database: 

NCP>SET CIRCUIT X25-0UTG0ING - 
_ TYPE X25 - 
_ OWNER EXECUTOR - 
_ USAGE OUTGOING - 
_ NUMBER 4561 - 
_ STATE ON 

The command must specify the DTE address and subaddress 
of the remote node. The value in the NUMBER parameter 
represents DTE 456 subaddress 1. 

On node B, the following command indicates that the DECnet 
Routing layer will accept all incoming calls to this node (DTE) 
that have a subaddress in the range 1-20: 

NCP>SET EXECUTOR SUBADDRESSES 1-20 

Note that this command must be issued at node B before node 
B can accept calls from node A. 

The following command at node B is then used to specify the 
incoming DLM circuit in the volatile database: 

NCP>SET CIRCUIT X25-INCOMING - 
_ TYPE X25 - 
_ OWNER EXECUTOR - 
_ USAGE INCOMING - 
_ STATE ON 
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3.5.8 




Circuit Counters 

DECnet-VAX automatically maintains certain statistics for 
circuits in the network. These statistics are known as circuit 
counters. For all circuits, counter information may include 
the number of data packets sent, received, and lost over the 
circuit; timeouts; and the amount of time since the counters 
were last zeroed. For DDCMP circuits, counters are maintained 
for timeouts and data and buffer errors, and for both DDCMP 
and Ethernet circuits, the number of bytes and data blocks 
sent and received. For X.25 circuits, the following statistics 
are indicated in counters: the time since the counters were 
zeroed; the number of bytes, data blocks and resets sent and 
received; and the number of resets initiated by the network. 
Information obtained from counters may be useful either 
alone or in conjunction with logging information to measure 
the performance and throughput for a given circuit. See the 
NCP section of the VAX/VMS Utilities Reference Volume for 
a complete list of circuit counters. Refer to Section 2.9 for a 
discussion of logging. 

You can use NCP to regulate the frequency with which circuit 
counters are logged and when they are zeroed. At any point 
while the network is running, you can also display circuit 
counter statistics using the SHOW CIRCUIT COUNTERS 
command. 

To set a timer whose expiration automatically causes the circuit 
counters to be logged at the logging sink and then zeroed, 
use the SET CIRCUIT command with the COUNTER TIMER 
parameter. The following command causes a circuit counter 
logging event to take place every 600 seconds: 

NCP>SET CIRCUIT DMC-0 COUNTER TIMER 600 

To clear this parameter, use the NCP command below. 

NCP>CLEAR CIRCUIT DMC-0 COUNTER TIMER 

At any point when the network is running, you can zero 
counters for a given circuit or for all known circuits. Use the 
following commands to zero circuit counters: 

NCP>ZER0 CIRCUIT DMC-0 COUNTERS 
NCP>ZER0 KNOWN CIRCUITS COUNTERS 
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3.6 Line Commands 

DECnet-VAX supports four classes of lines: DDCMP, Cl, 
Ethernet, and X.25. You must use NCP commands to identify 
all physical lines connected to the local node and to specify 
parameters that affect operation of the lines. This section 
describes line identification and discusses the line parameters 
you can use. 


3.6.1 Line Identification 

As with nodes and circuits, lines must have unique identifiers. 
The line and circuit names identify a logical connection. For 
VAX/VMS, line identification takes one of the following 
formats: 

dev-c 
dev-c[-u] 

dev Is a device name. (Refer to the NCP section in the VAX/VMS 
Utilities Reference Volume for a complete list of mnemonic 
device names.) 

c Is a decimal number (0 or a positive integer) designating the 
device's hardware controller. 

u Is a decimal unit or line number (0 or a positive integer) 
included if the device is a multiple unit line controller. For 
all non-multiplexed lines, the unit number is optional and, if 
specified, is always zero (0). 

Note: Devices which are similar in operation are referred to by the 
same mnemonic. 

VAX/VMS maps network management line names to system- 
specific line names (for example, DMC-4 maps to XMEO). 
Network management line names provide network-wide line 
identification independent of individual operating system 
conventions. 

The following commands illustrate line identification. The 
command below specifies a synchronous DDCMP point-to- 
point line, identifying the DMC (or DMR) line device and 
controller number 0: 

NCP>SET LINE DMC-0 STATE ON 
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The command below specifies an asynchronous DDCMP point- 
to-point line. It identifies the DMF32 asynchronous line unit by 
the mnemonic TX and specifies controller number 0 and unit 
number 0 (that is, TXAO). 

NCP>SET LINE TX-0-0 RECEIVE BUFFERS 4 STATE ON 

When you turn on an asynchronous line, it is advisable to 
set the number of receive buffers to a value of 4 or more (see 
Section 3.6.3.1). 

Note that dynamic asynchronous DDCMP line names 
are supplied automatically when a dynamic connection is 
established. 

The following command specifies the Cl line CI-0: 

NCP>SET LINE CI-0 STATE ON 

The command below specifies the Ethernet line UNA-0: 

NCP>SET LINE UNA-0 STATE ON 

The command below specifies the X.25 line DUP-0: 

NCP>SET LINE DUP-0 STATE ON 

For each X.25 line, specify a unique device: 

DMF-0 

DUP-0 

KMX-0-0 

KMX-0-1 


3.6.1.1 Line Protocols 

As part of the process of identifying lines, you must specify the 
line protocol. To ensure that the data link protocol operates 
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properly when information is transferred over a line, use the 
SET LINE command with the PROTOCOL parameter to specify 
a line protocol. There are six protocols: 

DDCMP CONTROL Specifies the line as a multipoint control 


DDCMP DMC 

station. You can set multiple circuits for 
CONTROL lines. Each circuit must have a 
unique physical tributary address. 

Specifies that the line is in DMC emulator 
mode. DMC is similar to DDCMP POINT 
protocol, except that DMC uses an older 
version of DDCMP (Version 3.2). This 
protocol should be set for the local line 
when the remote line is a DMC. 

DDCMP POINT 

Specifies the line as one end of a point- 
to-point DDCMP connection. You may 
specify only one circuit per POINT line. 

DDCMP TRIBUTARY 

Specifies that the line is a multipoint 
tributary end of a DDCMP multipoint 
group. You may specify only one circuit 
per TRIBUTARY line. 

ETHERNET 

Specifies the line is a multiaccess line that 
uses the Ethernet protocol. 

LAPB 

Specifies the line uses the X.25 level 2 
protocol and must be a line for the X25- 
PROTOCOL module. All X.25 lines are 
also referred to as LAPB lines. 


Note that you do not specify any protocol for a Cl line. The 
Cl uses its own private protocols for communication between 
nodes. 

If you do not specify a line protocol, the default values below 
apply, according to the device specified. 
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3.6.2 


Device 

Protocol 

DMC/DMR 

DDCMP POINT 

DMP/DMV 

DDCMP POINT 

DMF 

DDCMP POINT 

TT/TX 

DDCMP POINT 

DUP/DPV 

LAPB 

KMX 

LAPB 

KMY 

LAPB 

QNA 

ETHERNET 

UNA 

ETHERNET 

Cl 

None (not specified) 


The SET LINE PROTOCOL examples below specify line 
protocols in the configuration database at the local node and on 
remote nodes other than DECnet-VAX, such as DECnet-RSX. 
For example, the command below identifies line DMP-0 as a 
multipoint control station: 

NCP>SET LINE DMP-0 PROTOCOL DDCMP CONTROL 

You set this parameter in the database of the local node at the 
controlling end of this line. A tributary for this line could be 
specified as 

NCP>SET LINE DMP-1 PROTOCOL DDCMP TRIBUTARY 

You set this parameter in the database of the remote node 
connected to the tributary end of the control station for that 
line. 


Line Parameters 

The configuration database should contain line parameters for 
all physical lines connected to the local node or DTE. These 
parameters supply information used to control various aspects 
of a line's operation. Table 3-4 lists the types of lines and 
the line parameters applicable to them. Table 3-5 lists all line 
parameters by function. 
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Table 3-4 Types of Lines and Applicable Line Parameters 


Type of Line 


Applicable Line Parameters 


All lines 


All lines except 
X.25 lines 

All lines except 
Ethernet lines 

DDCMP lines 


Asynchronous 
DDCMP lines 

X.25 lines 


CONTROLLER controller-mode 
COUNTER TIMER seconds 
PROTOCOL protocol-name 
STATE (ON \ 

(OFF f 

LINE BUFFER SIZE number 
RETRANSMIT TIMER millisecond 


CLOCK clock-mode 
DEAD TIMER milliseconds 
DELAY TIMER milliseconds 
DUPLEX duplex-mode 
RECEIVE BUFFERS count 
SCHEDULING TIMER milliseconds 
SERVICE TIMER milliseconds 
STREAM TIMER milliseconds 

HANGUP option 
LINE SPEED number 
SWITCH option 
MAXIMUM BLOCK count 
MAXIMUM RETRANSMITS count 
MAXIMUM WINDOW count 
MICROCODE DUMP file-id 
PROTOCOL LAPB 
STATE SERVICE 


Table 3-5. Line Parameters and Their Function 


Parameter Function 


Parameters 


Defines line protocol 


PROTOCOL 


DDCMP CONTROL 
DDCMP POINT 
DDCMP DMC 
DDCMP TRIBUTARY 
ETHERNET 
LAPB 
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Table 3-5 (Cont.) 

Line Parameters and Their Function 

Parameter Function 

Parameters 


Sets counter timer for line counter 
event logging 

Selects clock type 

Sets line's operational state 


Sets maximum receive buffer size 
for logical links over specific line 


COUNTER TIMER seconds 

CLOCK (INTERNAL ) 

(EXTERNAL ) 

STATE (OFF 

\ ON 

(SERVICE 
LINE BUFFER SIZE number 


Sets number of buffers in receive 
queue 

Establishes physical line control 
parameters for DDCMP protocol 


Specifies asynchronous DDCMP 
line characteristics 


Establishes line-level loopback 
control for controller operation 

Establishes frame control 
parameters for X.25 line 

Controls retransmission of frames 
for X.25 line 


RECEIVE BUFFERS number 

DUPLEX ( FULL ) 

( HALF j 

DEAD TIMER milliseconds 
DELAY TIMER milliseconds 
RETRANSMIT TIMER milliseconds 
SCHEDULING TIMER milliseconds 
SERVICE TIMER milliseconds 
STREAM TIMER milliseconds 
HANGUP (DISABLED) 

(ENABLED f 
LINE SPEED number 
SWITCH (DISABLED) 

(ENABLED f 

CONTROLLER (LOOPBACK) 
(NORMAL f 

MAXIMUM BLOCK count 
MAXIMUM WINDOW count 

MAXIMUM RETRANSMITS count 
RETRANSMIT TIMER 


Use the SET LINE command to establish and modify these 
parameters. The line must be set to OFF if you wish to modify 
any parameters except COUNTER TIMER, SERVICE, SERVICE 
TIMER, and STATE. STATE is a required parameter for all lines 
that you specify in the configuration database. Use the CLEAR 
LINE command to reset parameters to their default values (if 
any) in the volatile database. The line must be off before you 
specify the ALL parameter in the CLEAR LINE command. 
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Note that not all circuit devices support all parameters listed 
in the above tables. If a particular device does not support a 
parameter, an error message may be displayed. Refer to the 
VAX/VMS I/O User's Reference Manual: Part II for information 
on specific circuit devices. 


3.6.2.1 Operational State of Lines 

As with local node and circuit states, you can control the 
operational state of lines connected to the local node or to the 
local DTE. There are three possible line states: 

OFF Allows no traffic over a line. The line is unavailable 

for network activity. 

ON Allows traffic over the line. The ON state is the 

normal operational state, which allows complete 
route-through and downline loading operations. 
SERVICE Allows only restricted line service over the line. This 
traffic includes loopback testing. (Used only for X.25 
lines.) 

The ON and SERVICE states have substates; see the NCP 
section in the VAX/VMS Utilities Reference Volume for a 
complete list of line states, substates, and their transitions. 

Use the STATE parameter to specify the operational state of a 
line. For example, to allow normal traffic over line DMC-0, use 
the following command: 

NCP>SET LINE DMC-0 STATE ON 

The command below specifies the operational state of an X.25 
line, allowing normal traffic over the DUP-0: 

NCP>SET LINE DUP-0 STATE ON 

The STATE parameter is optional and, by default, is set to OFF. 
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3.6.2.2 Line Buffer Size 

You can increase the maximum size of receive buffers (and 
therefore the size of NSP messages) that can be transmitted 
over a particular line by specifying the LINE BUFFER SIZE 
parameter in the SET LINE command. For certain logical links 
established over that line to adjacent nodes, this value overrides 
the executor node BUFFER SIZE limit specified in the SET 
EXECUTOR command (see Section 3.3.4.1). 

If you specify the LINE BUFFER SIZE parameter for a line, 
the adjacent node on any new logical link initiated over that 
line can optionally accept an NSP message segment size that 
is based on the LINE BUFFER SIZE value. If the remote node 
accepts the segment size, the logical link to that node is then 
tied to that circuit. If the circuit fails, the logical link does not 
automatically route the packet through another alternate circuit, 
that is, the logical link becomes nonadaptive. 

For example, the following command sets the maximum size 
of receive buffers for line UNA-0 to 1400 bytes, but only for 
logical links to adjacent nodes that accept 1400 bytes as the 
NSP segment size. 

NCP>SET LINE UNA-0 LINE BUFFER SIZE 1400 

If the adjacent node does not accept a segment size based on 
the LINE BUFFER SIZE value, the default for any line except an 
Ethernet line is the executor node's BUFFER SIZE value. The 
default for an Ethernet line is 1498 bytes. 

This feature can be used to maximize performance over high¬ 
speed links such as Ethernet, by using a large value for the 
LINE BUFFER SIZE parameter and causing all logical links 
between adjacent nodes on the Ethernet to use that larger 
message size. 
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I 3.6.3 



DDCMP Line Parameters 


Several parameters regulate various aspects of a DDCMP line's 
physical protocol operation. You can specify the number of 
receive buffers, the duplex mode, and the timers for both 
normal and service operations. 

Parameters that apply specifically to asynchronous DDCMP 
lines indicate the speed of the line, whether modem signals 
are dropped when a line is shut down, and whether an 
asynchronous line is switched back to a terminal line when 
disconnected from the network. For a dynamic asynchronous 
line, DYNSWITCH supplies these parameters to NETACP 
automatically. 

DDCMP line parameters are described below. 


3.6.3.1 


Line Buffers 

To allocate buffers for data reception by the device driver for a 
particular DDCMP line, use the RECEIVE BUFFERS parameter. 
The following command sets 4 buffers for this line: 


NCP>SET LINE DMC-1 RECEIVE BUFFERS 4 


Values for this parameter range from 1 to 32. The number 
of buffers you set will depend on throughput requirements 
and available memory pool. A value in the range of 2 to 
4 is adequate for line speeds of less than 56K bits. For 
asynchronous lines, a value of at least 4 is recommended. 
Megabit line speeds may require eight or more buffers, 
depending on the observed errors. For LAPB lines, see the 
description of X.25 line parameters in Section 3.6.5. 


3.6.3.2 


Duplex Mode 

To set the duplex mode for a DDCMP line, use the DUPLEX 
parameter. For example, the following command sets the mode 
of the DMC11 device controller to full duplex for line DMC-1: 

NCP>SET LINE DMC-1 DUPLEX FULL 


Generally, you use full-duplex mode for local lines and 
permanently wired telephone lines; you usually use half-duplex 
mode for dialup remote telephone lines used with half-duplex 
modems. If you use a modem, consult the manufacturer's 
documentation for full- or half-duplex characteristics. 
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3.6.3.3 Line Timers 

Line timers control the frequency of message retransmission at 
the DDCMP level. There are six line timers. 

• Service timer. The service timer sets the maximum amount 
of time allowed to elapse before a retransmission is 
necessary when service operations are underway. 

• Retransmit timer. The retransmission timer sets the 
maximum amount of time allowed to elapse before a 
retransmission is necessary on a multipoint line. This is the 
amount of time a control station will wait for a tributary to 
respond. For a DMF32 tributary, it is the maximum amount 
of time the tributary will hold the line before returning 
control to the control station. For an X.25 line, it is the 
maximum amount of time before a frame is retransmitted 
(see Section 3.6.5.1). 

• Dead timer. The dead timer sets the amount of time 
between polls of the dead tributaries. 

• Delay timer. The delay timer sets the amount of time to 
delay between polls. 

• Scheduling timer. The scheduling timer sets the time limit 
between recalculations of tributary polling priorities. 

• Stream timer. The stream timer sets the amount of time that 
a tributary or half-duplex remote station is allowed to hold 
the line. 

The DMP11 automatically handles message retransmission for 
normal operations. However, when a DDCMP circuit is in the 
SERVICE state, a line retransmission timer is necessary because 
the DMP11 does not handle retransmission in maintenance 
operation protocol (MOP) mode. 

In general, to calculate the best value for the retransmit timer, 
use the following formula: 

RETRANSMIT TIMER = (20000 * buffer-size * number-of-buffers)/bps-of-line 


The number of buffers is the value specified for the MAXIMUM 
TRANSMITS parameter in the SET CIRCUIT command; it 
represents the maximum number of data messages that 
the tributary can transmit in a single poll interval (see 
Section 3.5.3.2). 
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Assume an example with a buffer size of 576, a line of 56K bits 
per second (bps), and four buffers per selection interval. The 
formula would be calculated as shown below. 

RETRANSMIT TIMER = (20000 * 576 * 4)/56000 = 820 milliseconds 

To set a retransmit timer for a DDCMP line, use the 
RETRANSMIT TIMER parameter, as shown below. 

NCP>SET LINE DMP-2 RETRANSMIT TIMER 820 

This command sets the retransmission frequency for line DMP- 
2 to 820 milliseconds. If a message is not acknowledged in 820 
milliseconds, it will be retransmitted. 

The above formula does not apply to the DMF-32 tributary 
mode. The value of the retransmit timer is the maximum 
time the tributary will hold the line before returning control 
to the control station. For DMF-32 tributary mode, therefore, 
the more active the tributary, the higher the value to which 
you should set the retransmit timer (a value of 2000 is 
recommended). For inactive tributaries, set the timer value 
lower (a value of 500 milliseconds is recommended). 


3.6.3.4 Asynchronous DDCMP Line Parameters 

The LINE SPEED, HANGUP, and SWITCH parameters 
apply only to asynchronous DDCMP lines. Values for these 
parameters are provided automatically when a line is switched 
dynamically from a terminal line to an asynchronous DDCMP 
line. When you initiate a dynamic connection between two 
nodes over a telephone line, these parameters are included in 
the line entries NETACP supplies to the NCP database. For 
static asynchronous DDCMP lines, these parameters usually 
assume their default values. 

The LINE SPEED parameter specifies in baud the speed of 
an asynchronous DDCMP line. The parameter defaults to 
the current speed of the line. If two asynchronous lines 
are connected, both lines must have the same line speed. 

If a dynamic connection is made, this value is supplied 
automatically for each line. For a static asynchronous line, the 
default line speed value is the value of the /SPEED qualifier 
in the $SET TERMINAL command you specified to cause the 
terminal line to be converted to an asynchronous line. 
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3.6.4 


The HANGUP parameter determines whether the modem 
signal is dropped when the line is shut down. When you 
shut down a dynamically switched asynchronous line, the 
modem carrier will be dropped if the value of the parameter 
is HANGUP ENABLED. This value, supplied automatically, 
corresponds to the /HANGUP qualifier in the $SET TERMINAL 
command you specified to cause the terminal line to be 
switched to an asynchronous line. If the value supplied for 
the parameter is HANGUP DISABLED, the modem signal 
will not be dropped when the line is shut down. For a 
static asynchronous line, the parameter defaults to HANGUP 
ENABLED. 

The SWITCH parameter indicates whether an asynchronous 
DDCMP line is to be switched back to a terminal line after it 
is disconnected from the network (when the channel to the 
network is deassigned). The SWITCH parameter is enabled 
automatically for a dynamic asynchronous line so that the line 
can be switched back to a terminal line when the dynamic 
connection is broken. The parameter defaults to SWITCH 
DISABLED for a static asynchronous line, which remains 
available as a communications line even when not assigned a 
channel to the network. Generally, the user does not need to 
set the SWITCH parameter manually. 


Ethernet Line Parameters 

Ethernet lines do not support any service functions. Parameters 
the Ethernet lines have in common with other DECnet lines 
are the COUNTER TIMER, PROTOCOL, STATE, and LINE 
BUFFER SIZE parameters. The LINE BUFFER SIZE parameter 
can be used to optimize performance over a high-speed data 
link such as an Ethernet (see Section 3.6.2.2). 

The Ethernet address associated with the Ethernet line device 
hardware is displayed as a read-only parameter, HARDWARE 
ADDRESS, in response to the SHOW LINE command. The 
command 

NCP>SHOW LINE UNA-0 CHARACTERISTICS 

will result in the following information being displayed for 
UNA-0: 

Protocol = Ethernet 

Hardware address = AA-00-03-00-Q0-0C 
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See the discussion of Ethernet physical addresses in 
Section 2.1.1, and the general description of the format of 
Ethernet addresses in Section 3.3.3. 


3.6.5 X.25 Line Parameters 

All X.25 lines must specify the LAPB protocol. (X.25 lines are 
referred to as LAPB lines.) The line parameters unique to X.25 
lines include the MAXIMUM RETRANSMITS, MAXIMUM 
BLOCK, and MAXIMUM WINDOW parameters. 


3.6.5.1 Frame Control for X.25 Lines 

The MAXIMUM BLOCK and MAXIMUM RETRANSMIT 
parameters control the size and transmission of frames over 
an X.25 line; the RETRANSMIT TIMER and MAXIMUM 
RETRANSMIT parameters control the retransmission of frames. 
The MAXIMUM WINDOW parameter controls the number of 
frames for which outstanding acknowledgments are allowed. 

Use the RETRANSMIT TIMER parameter to control the 
frequency of frame retransmission at X.25 level 2 on LAPB 
lines. For example, the command below sets the retransmission 
frequency to 500 milliseconds for the line DUP-0: 

NCP>SET LINE DUP-0 ... RETRANSMIT TIMER 500 ... 

In other words, if a frame is not acknowledged in 500 
milliseconds, it is retransmitted. 

The value for this parameter depends on the size of the frame 
and the speed of the LAPB line; refer to the appropriate PSI 
reference card for recommended values. Specify a value in the 
range 1 to 65,535. 

The RETRANSMIT TIMER parameter is optional and, by 
default, takes the network value. Refer to the appropriate PSI 
reference card for the network value of this parameter. 

To specify the maximum number of times a frame is 
retransmitted over a specified LAPB line, use the MAXIMUM 
RETRANSMITS parameter. For example, the following 
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command indicates that if a frame is not acknowledged in 500 
milliseconds it is retransmitted and that this operation is to be 
performed a maximum of 10 times: 

NCP>SET LINE DUP-0 ... RETRANSMIT TIMER 500 - 
_ MAXIMUM RETRANSMITS 10 ... 

Specify a value in the range 1 to 255. 

The MAXIMUM RETRANSMITS parameter is optional and, by 
default, takes the network value. Refer to the appropriate PSI 
reference card for the network value of this parameter. 

To specify the maximum size of the frame for a particular LAPB 
line, use the MAXIMUM BLOCK parameter. For example, the 
following command sets the size of the frame to 133 bytes for 
the line DUP-0: 

NCP>SET LINE DUP-0 ... MAXIMUM BLOCK 133 ... 


The size of the frame must always be at least 5 bytes larger 
than the maximum packet size (see Section 3.4.4.1). Specify a 
value in the range 21 to 1029. If you subscribe to the fast select 
facility, the minimum size of the frame is 213 bytes. 

The MAXIMUM BLOCK parameter is optional and, by default, 
takes the network value. Refer to the appropriate PSI reference 
card for the network value of this parameter. 

To specify the maximum number of frames for which there are 
outstanding acknowledgments for a particular X.25 line, use the 
MAXIMUM WINDOW parameter. For example, the command 
below sets the maximum to 2 for the line DUP-0: 

NCP>SET LINE DUP-0 ... MAXIMUM WINDOW 2 ... 

The MAXIMUM WINDOW parameter is optional and, by 
default, takes the network value. Refer to the appropriate PSI 
reference card for the network value of this parameter. 
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3.6.5.2 Receive Buffers for X.25 Lines 

Optionally specify the number of buffers in the receive queue 
of any X.25 lines. Use the RECEIVE BUFFERS parameter, for 
example: 

NCP>SET LINE DUP-0 ... RECEIVE BUFFERS 4 ... 

Specify a value in the range 2 to 32. By default, the number 
of buffers is 3. This value is normally adequate for DUP line 
speeds. 


3.6.6 Line Counters 

DECnet software automatically maintains statistics for certain 
lines in the network. These statistics are known as line 
counters. Line counters for DDCMP lines include the number 
of bytes and data blocks sent and received, local and remote 
process errors, and the amount of time since the counters were 
last zeroed. DECnet-VAX presently maintains these counters 
only for DMP-11 and DMF-32 lines. Line counters for Ethernet 
lines include the number of bytes, multicast bytes, data blocks, 
and multicast blocks sent and received; the number of blocks 
deferred or sent after collision; and the number of send failures 
and discarded frames. This counter information may be useful 
alone or in conjunction with logging information to measure 
the performance and throughput for a given line. Refer to 
Section 2.9 for a discussion of logging. 

VAX PSI automatically maintains statistics for X.25 lines in 
the network. These statistics are also called line counters, but 
are used for X.25 lines only. Such information may include 
bytes and data blocks sent and received; inbound and outbound 
data errors; and remote and local reply timeouts, buffer errors, 
and process errors. These counters, together with component 
characteristics, are useful in monitoring the activity of X.25 
lines. The counters may, for example, be employed to measure 
the performance and throughput of a given X.25 line. 

You can use NCP to affect the frequency with which counters 
are logged and when the counters are zeroed. At any point 
while the network is running, you can also display line counter 
statistics using the SFiOW LINE COUNTERS command. 
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To set a timer whose expiration automatically causes the line 
counters to be logged at the logging sink (location) and then 
zeroed, use the SET LINE command with the COUNTER 
TIMER parameter. The command below causes a line counter 
logging event to take place every 600 seconds. 

NCP>SET LINE DMC-0 COUNTER TIMER 600 

To clear this parameter, use the NCP command 

NCP>CLEAR LINE DMC-0 COUNTER TIMER 

At any point when the network is running, you can zero 
line counters for a given line or for all known lines. Use the 
following commands to zero line counters: 

NCP>ZER0 LINE DMC-0 COUNTERS 
NCP>ZER0 KNOWN LINES COUNTER 


3.7 Routing Commands 

As network or system manager, you can use certain NCP 
command parameters to specify how the network is to 
be configured into routing and nonrouting nodes and into 
areas. Other NCP parameters indirectly control the path data 
takes through the network, and control the timing of routing 
messages; these parameters have reasonable default values 
for most networks. If the network is very large, it may be 
helpful to have a network manager, rather than individual 
system managers, be responsible for controlling the flow of data 
through the network. 


3.7.1 Specifying the Node Type 

The type of node is specified in the TYPE parameter of the 
DEFINE EXECUTOR command. DECnet-VAX supports three 
values for the node-type: NONROUTING IV, ROUTING IV, 
and AREA. The type of a Phase IV end node is NONROUTING 
IV, the type of a Phase IV level 1 router is ROUTING IV, and 
the type of a Phase IV level 2 router is AREA. For example, 
to designate the executor as a Phase IV nonrouting node (end 
node), specify 

NCP>DEFINE EXECUTOR TYPE NONROUTING IV 
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3.7.2 


To specify the executor as a level 2 router in an area network 
configuration, enter 

NCP>DEFINE EXECUTOR TYPE AREA 

The default value for node-type depends on the particular type 
of DECnet-VAX license key installed (see Section 2.4.1.1). If 
the key is for a full function license (supporting routers and end 
nodes), the default value of the TYPE parameter is ROUTING 
IV; if the key is for an end node license, the default (and only 
value possible) is NONROUTING IV. 

Note that you cannot change the executor node type while 
DECnet is running. You must shut down the network, use the 
DEFINE command to change the executor node type, and then 
restart the network. 

The SHOW EXECUTOR CHARACTERISTICS command 
displays the node type of the executor node. The SHOW 
NODE STATUS command displays the node type of a specified 
adjacent node. The possible values of node-type are area, 
routing IV, nonrouting IV, routing III, nonrouting III, or phase 
II. A Phase IV node can be a level 2 router (area), a level 1 
router (routing IV), or an end node (nonrouting IV). A Phase 
III node can be either a router (routing III) or an end node 
(nonrouting III). 


Specifying the Area Number in a Node Address 

To configure a network for area routing, assign each node to a 
specific area which has a unique number. The area number is a 
decimal number, in the range 1 through 63, which appears as a 
prefix on the decimal node number of the individual node. The 
node number must be unique within the area. The area number 
and the node number are separated by a period. The format of 
a node address in an area network is 

area-number.node-number 


For example, node 300 in area 40 has an node address of 
40.300. 

To set the node address for the local node in an area 
configuration, use the SET EXECUTOR command with the 
ADDRESS parameter, as below. 

NCP>SET EXECUTOR ADDRESS 40.300 
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Configuration of a network requires that each node be assigned 
a node address containing an appropriate area number. If you 
do not specify an area number in a node address, the executor 
area number is used. 

A Phase IV node address can be converted to a decimal 
equivalent for use in DCL commands, such as COPY, and in 
sending messages using the Mail Utility. The algorithm to 
convert the address to its decimal equivalent is 

(area-number * 1024) + node-number 

The address can also be converted to its hexadecimal equivalent 
for incorporation in the Ethernet physical address of the node 
(see Section 3.3.3). 

It is generally more convenient to refer to a node by name. 


3.7.3 Setting Routing Configuration Limits 

During configuration of the network, you can establish certain 
limits related to routing over the network. You can limit the 
number of routers allowed on a single Ethernet and the number 
of routing and end nodes permitted on all Ethernet circuits to 
which the local node is attached. If the network is grouped into 
areas, you can limit the number of areas allowed. 


3.7.3.1 Maximum Number of Ethernet Routers and End Nodes 

Allowed 

Certain NCP command parameters limit the number of routers 
and end nodes that can be configured on Ethernet circuits. Use 
the SET CIRCUIT command with the MAXIMUM ROUTERS 
parameter to set the maximum number of routers permitted 
on a particular Ethernet circuit. The largest number of routers 
allowed on an Ethernet is 33, which is the default value of the 
MAXIMUM ROUTERS parameter. Note that the recommended 
limit on the number of routers on a single Ethernet circuit is 
10, because of the control traffic overhead (routing messages 
and system identification messages) involved. For example, the 
following command specifies that no more than 5 routers can 
exist on Ethernet circuit UNA-0. 

NCP>SET CIRCUIT UNA-0 MAXIMUM ROUTERS 5 
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Use the SET EXECUTOR command with the MAXIMUM 
BROADCAST ROUTERS parameter to specify the maximum 
number of routing nodes that will be permitted on all Ethernet 
circuits to which the local node is attached. Each routing node 
can be either a level 1 router (capable of routing within its own 
area, if area routing is specified) or a level 2 router (capable 
of routing within its own area and outside of its area). For 
example, the following command specifies that a maximum of 
12 routers is allowed on Ethernet circuits to which the executor 
node is connected: 

NCP>SET EXECUTOR MAXIMUM BROADCAST ROUTERS 12 

The default value of this parameter is 32. 

Use the SET EXECUTOR command with the MAXIMUM 
BROADCAST NONROUTERS parameter to set the maximum 
number of nonrouting nodes (end nodes) permitted on all 
Ethernet circuits to which the local node is attached. For 
example, the following command specifies that no more than 
20 end nodes can exist on all Ethernet circuits to which the 
executor node is connected. 

NCP>SET EXECUTOR MAXIMUM BROADCAST NONROUTERS 20 

The default value is 64. 


3.7.3.2 Maximum Number of Areas Allowed 

When configuring an area network, use the SET EXECUTOR 
command with the MAXIMUM AREA parameter if you want 
to set a limit on the number of areas that the executor node's 
Routing layer will recognize. For example, if you want a 
maximum of 50 areas to be recognized, specify the command 

NCP>SET EXECUTOR MAXIMUM AREA 50 

If this parameter is not specified, the Routing layer will 
recognize up to 63 areas. 
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3.7.4 Routing Control Parameters 

NCP supports routing parameters that provide for circuit cost 
control (COST), control of the total path between any two 
nodes (MAXIMUM COST, MAXIMUM HOPS), and route- 
through control (MAXIMUM VISITS). For a network divided 
into areas, the routing parameters for maximum cost and length 
of the path between areas in the network (AREA MAXIMUM 
COST, AREA MAXIMUM HOPS) also apply. These parameters 
are used to control the path that data is likely to take when 
being transmitted through the network, and to minimize 
congestion at particular nodes in the network. For most 
networks, the default values of these parameters are reasonable. 


3.7.4.1 Circuit Cost Control Parameter 

Figure 3-2 illustrates sample circuit costs attributed to the 
network example. The following paragraphs discuss routing 
control parameters as they relate to Figure 3-2. 

The COST parameter in the SET CIRCUIT command specifies 
the circuit cost. For example, the following command sets a 
cost for the circuit connecting node BOSTON to node NYC: 

NCP>SET CIRCUIT DMC-2 COST 1 

This command sets a low cost for the circuit. Numbers in the 
range of 1 to 25 are valid circuit costs. The default value is 10. 

It is recommended that you establish a circuit cost standard that 
is uniform across the entire network. The following algorithm 
is used to determine appropriate circuit costs. The algorithm is 
based on circuit delay. Delay is based on circuit bandwidth. 

1 where the bandwidth is greater than 100K bits per second 

x where x is approximately equal to 100,000 divided by the 

bandwidth, and where the bandwidth is greater than 4K bits 
per second but less than 100K bits per second 

25 where the bandwidth is less than 4K bits per second or the 
circuit is an X.25 circuit 
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Figure 3-2 Network Circuit Costs 
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3.7.4.2 Maximum Path Control Parameters 

Both the maximum cost for all circuits to the destination node 
(MAXIMUM COST) and the maximum hops that a packet can 
make when routed to the destination node (MAXIMUM HOPS) 
are set using the SET EXECUTOR command. These parameters 
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are used to ascertain whether a destination is reachable. The 
value of the MAXIMUM HOPS parameter should always be 
equal to or greater than the longest possible path within the 
network. For the network example, a maximum hop parameter 
value of 6 is sufficient. The maximum cost and hops values 
should be chosen carefully, with regard to the intended use 
of the network, the actual network configuration, and possible 
failures. The default values of these parameters are reasonable 
for most networks. 

The following example indicates the use of the SET EXECUTOR 
command to specify the maximum cost and hops allowed for 
network routing. 

NCP>SET EXECUTOR MAXIMUM COST 100 MAXIMUM HOPS 6 

Values in the range 1 to 1022 are valid for the MAXIMUM 
COST parameter; the default value is 1022. Values in the 
range 1 to 30 are valid for the MAXIMUM HOPS parameter; 
the default value is 30. The value for the MAXIMUM 
HOPS parameter must be less than or equal to the value 
for MAXIMUM VISITS. Use as small a number as possible in 
these ranges. 

Figure 3-2 illustrates the relationship between circuit costs 
and path costs. To send a packet from TRNTO to DALLAS, 
the system can route it over one of two paths, both of which 
require two hops; the first path is through BOSTON, the 
second through DENVER. However, because the path through 
BOSTON has a cost of 8 and the path through DENVER has a 
cost of 5, the system will route the packet through DENVER. 

Under normal conditions, a MAXIMUM HOPS value of 3 
would be sufficient for the network in Figure 3-2. However, 
if the MAXIMUM HOPS value were set to 3, a failure of the 
TRNTO-BOSTON circuit would render TRNTO unreachable 
from NYC, KANSAS, or BANGOR, even though a physical 
path still exists (the four-hop path NYC-BOSTON-DALLAS- 
DENVER-TRNTO). Consideration of possible failures is also 
important in establishing the MAXIMUM COST parameter. 
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3.7.4.3 Route-Through Control Parameter 

The MAXIMUM VISITS parameter in the SET EXECUTOR 
command specifies the maximum number of nodes a packet can 
be routed through before arriving at the destination node. For 
example, the following command sets the number of visits to 
12: 

NCP>SET EXECUTOR MAXIMUM VISITS 12 

If the number of nodes that the data packet visits exceeds 
the value of MAXIMUM VISITS, the packet is discarded. 
Generally, use a value that is two or three times the value for 
the MAXIMUM HOPS parameter. At a minimum, the value 
for the MAXIMUM VISITS parameter must be greater than the 
value for the MAXIMUM HOPS parameter. The maximum 
value is 63, which is also the default value. 


3.7.4.4 Area Path Control Parameters 

When a network is divided into areas, the MAXIMUM COST 
and MAXIMUM HOPS parameters described above are used 
to control the path between nodes within each area. A second 
set of routing parameters (AREA MAXIMUM COST, AREA 
MAXIMUM HOPS) are used to control the total cost and length 
of paths between level 2 routers within the whole network. In 
effect, these parameters control the total possible path between 
areas in the network. 

The AREA MAXIMUM COST parameter in the SET 
EXECUTOR command specifies the limit on the total path 
cost between the local level 2 router and any level 2 router in 
the network. This value is the maximum cost of circuits on the 
longest path between Level 2 routers. The AREA MAXIMUM 
HOPS parameter in the SET EXECUTOR command specifies 
the maximum number of hops that a packet can make between 
the local level 2 router and any other level 2 router in the 
network. The AREA MAXIMUM COST and AREA MAXIMUM 
HOPS parameters are used to determine whether an area 
is reachable. The default values for these parameters are 
reasonable. Selection of other values should be made carefully, 
with regard for the level 2 (area) topology of the network. 

The following example illustrates the use of the SET 
EXECUTOR command to specify the maximum cost and hops 
permitted for routing between level 2 routers in the network: 

NCP>SET EXECUTOR AREA MAXIMUM COST 500 AREA MAXIMUM HOPS 10 
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3.7.5 


Values in the range 1 to 1022 are valid for the AREA 
MAXIMUM COST parameter; the default value is 1022. Values 
in the range 1 to 30 are valid for the AREA MAXIMUM HOPS 
parameter; the default value is 30. 


Routing Message Timers 

Routing messages exchanged between adjacent nodes contain 
information about the cost and hops to each node in the 
network. Routing update messages are sent automatically 
whenever there is a change in the information (for example, 
when a line goes down). Nodes that detect the change (for 
example, nodes at each end of a line that failed) are the 
first to send routing update messages. The changed routing 
information then propagates as far as necessary to update all 
routers. 

Routing updates are also sent periodically under control of the 
routing timers. These periodic transmissions ensure that routing 
tables are kept up to date even in the unlikely event that a 
routing update message is lost. 

The timer for transmission of routing messages is set using the 
SET EXECUTOR command. For nodes on non-Ethernet circuits, 
the timer is called the routing timer. Changing the setting 
of the routing timer will cause additional routing messages 
to be transmitted to all adjacent nodes from the local node, 
at a specified interval. For example, this command sets the 
frequency of transmission of routing messages to 240 seconds: 

NCP>SET EXECUTOR ROUTING TIMER 240 

When this timer expires, the local node sends a routing message 
to all adjacent nodes. Numbers in the range of 1 to 65,535 are 
valid for the ROUTING TIMER parameter; the default value is 
600. It is recommended that you allow NETACP to supply the 
default. 

For a node on an Ethernet circuit, the timer is called the 
broadcast routing timer. When the timer expires, the local node 
sends a multicast routing configuration message to all nodes on 
the Ethernet. For example, this command sets the frequency of 
routing message transmissions to 30 seconds: 

NCP>SET EXECUTOR BROADCAST ROUTING TIMER 30 
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The broadcast routing timer for a node on an Ethernet circuit 
is set to a much lower value (approximately 30 to 40 seconds) 
than the routing timer for a node on a non-Ethernet circuit 
(every few minutes). Ethernet routing messages are sent more 
often so that full routing messages can be exchanged in case of 
datagram loss. The default value for this parameter is 40. 


3.7.6 Cl End Node Circuit Failover 

If a VAXcluster that uses the Cl as its DECnet datalink is 
configured to include end nodes as well as routers, it is possible 
to define a backup circuit in each end node that takes over 
should the primary circuit connecting the end node to its router 
fail. 

An example is a three-node cluster comprised of one router 
(R) and two end nodes (El and E2). Each end node should 
have a circuit defined to the router. It is possible to define a 
second circuit in each end node which connects to the other 
end node. The backup circuit is defined with a higher cost 
than the primary circuit, and its state is set on. Under normal 
circumstances, with all three nodes operational, the lower cost 
circuit (to the router) is used. Should the router shut down, 
this circuit will be shut down. The backup circuit will become 
the lowest cost circuit in the ON state, and will be used. The 
backup circuit allows the end nodes to communicate while the 
router is absent from the cluster. 

If nodes El, E2, and R have Cl port addresses 1, 2, and 3, 
respectively, this topology could be defined as follows in node 
El: 

NCP>DEFINE CIRCUIT CI-0.3 TRIBUTARY 3 COST 1 STATE ON 
NCP>DEFINE CIRCUIT CI-0.2 TRIBUTARY 2 COST 10 STATE ON 

The first circuit is the primary circuit; the second circuit is the 
backup circuit. 

This technique can be extended to a larger cluster with two 
routers and several end nodes; in each end node, two circuits 
of different cost are defined, one to each router. The network 
could then survive the failure of one router, but not both. 
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3.8 Logical Link Commands 

Use the SET EXECUTOR command to set logical link 
parameters that define the maximum number of active links 
permitted and set the timers that control NSP operation. Use 
the DISCONNECT LINK command to disconnect links while 
the network is running. 


3.8.1 Maximum Number of Links 

When defining parameters for the local node, you must specify 
the maximum number of logical links that can be active for 
that node. DECnet-VAX uses this value to determine the 
size of internal data structures. The command below sets the 
maximum number of links at 30: 

NCP>SET EXECUTOR MAXIMUM LINKS 30 

Note that this value includes both inbound and outbound 
logical links. In the example above, you can have only 15 links 
if both ends of all links are terminated locally. 


3.8.2 Disconnecting Logical Links 

You can selectively disconnect logical links active on the local 
node while the network is running. The first command below 
disconnects link 1827; the second disconnects all links active 
with all remote nodes. 

NCP>DISCONNECT LINK 1827 
NCP>DISCONNECT KNOWN LINKS 

Use the SHOW KNOWN LINKS command to obtain link status 
information, including link addresses, and to verify that links 
have been disconnected upon issuing these commands (see 
Section 3.3). DECnet-VAX maintains and uses link addresses. 

Optionally, you can disconnect a single link or all known links 
to a particular node. For example, the following NCP command 
disconnects all links to node TRNTO: 

NCP>DISCONNECT KNOWN LINKS WITH NODE TRNTO 
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3.8.3 Logical Link Protocol Parameters 

A variety of parameters exist for controlling NSP-related 
logical link activity. These parameters regulate the bounds 
for NSP connect sequences, inactivity intervals, and message 
retransmission. Another parameter limits the amount of 
nonpaged pool NSP will use for logical link transmission. You 
can change these parameters at any time, without affecting 
existing logical links. 


3.8.3.1 Incoming and Outgoing Timers 

There are two timers that regulate NSP connect sequences: an 
incoming timer and an outgoing timer. Use the INCOMING 
TIMER parameter to specify the maximum duration between 
the moment that a logical link connection is received for a 
process on the local node and the moment that the process 
accepts or rejects the connection. It is recommended that 
you use a value between 30 and 60. To allow 30 seconds for 
connection confirmation, use the following command: 

NCP>SET EXECUTOR INCOMING TIMER 30 

Expiration of this timer signals that a timeout has occurred. In 
effect, this timer protects the local node against a process that 
never responds to an inbound connection request. 

The OUTGOING TIMER parameter specifies a timeout value 
for the duration between the time a connection is requested 
and the time it is acknowledged by the destination node. It is 
recommended that you use a value between 30 and 60. For 
example, this command allows 30 seconds to elapse before a 
timeout is assumed to have occurred: 

NCP>SET EXECUTOR OUTGOING TIMER 30 

A typical value for this timer ranges from 10 to 90 seconds, 
depending on line speed and network diameter. The network 
diameter is the maximum diameter over the set of shortest 
paths between all pairs of nodes in the network. In effect, this 
timer protects the user on the local node against a connection 
request that never completes. 
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3.8.3.2 Inactivity Timer 

A logical link is inactive when no data is transmitted in either 
direction for a given interval of time. The inactivity timer 
regulates the frequency with which local DECnet software 
tests the viability of an inactive link, thereby protecting the 
user against a link that may be permanently unusable. Use 
the INACTIVITY TIMER parameter to specify the maximum 
duration of inactivity before the local node tests the viability of 
the link. For example, this command sets the inactivity interval 
to 60 seconds: 

NCP>SET EXECUTOR INACTIVITY TIMER 60 

When this timer expires, DECnet-VAX generates artificial traffic 
to test the link. The timer starts after an incoming message for 
the link has been processed. The timer is reset if any messages 
are received on the link. 


3.8.3.3 NSP Message Retransmission 

A third group of parameters regulates the frequency of NSP 
message retransmission. These are the DELAY WEIGHT, 
DELAY FACTOR, and RETRANSMIT FACTOR parameters for 
the local node. Use of default values for these parameters is 
recommended. 

NSP estimates the current delay in the round-trip transmission 
to a node with which it is communicating. The value of the 
DELAY WEIGHT parameter is used to calculate a new value 
of the estimated round trip delay. The old round trip delay 
is weighted by a function of this statistical factor to calculate 
the new round trip delay. If the delay weight is set high, the 
retransmit time changes slowly. If the weight is set low, the 
observed round trip time can change quickly if the observed 
round trip delays vary widely, and thus the retransmit time can 
change more rapidly. 

The value of the DELAY FACTOR parameter is multiplied by 
one-sixteenth of the estimated round trip delay time (derived 
as above) to determine the appropriate value for the time to 
retransmit certain NSP messages. 

Values in the range of 1 to 255 are used in specifying values for 
the DELAY FACTOR parameter, as in the following example: 

NCP>SET EXECUTOR DELAY WEIGHT 3 DELAY FACTOR 48 
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The default value is 80. Refer to the Network Services Functional 
Specification for a complete discussion of these concepts. 

The value of the RETRANSMIT FACTOR parameter regulates 
the number of times NSP will reattempt a transmission when 
its retransmission timer expires for a logical link. This value 
must be a number in the range of 1 to 65,535; the default value 
is 10. For example, the following command specifies that NSP 
will reattempt a transmission no more than 10 times: 

NCP>SET EXECUTOR RETRANSMIT FACTOR 10 

If NSP tries to retransmit an eleventh time, the logical link will 
disconnect. 

Note: Unless you have a special need to change the operating 

characteristics of a logical link, you should use the default 
values for DELAY WEIGHT, DELAY FACTOR, and 
RETRANSMIT FACTOR. In other words, do not define 
these parameters in the permanent database. 


3.8.3.4 Pipeline Quota 

The PIPELINE QUOTA parameter in the SET EXECUTOR 
command specifies the maximum number of bytes NCP will 
use from nonpaged pool to buffer logical-link transmit requests. 
In effect, this quota determines the number of packets NCP will 
transmit on a single logical link before waiting for a positive 
acknowledgment from the remote end of the link. The number 
of packets is determined by dividing the PIPELINE QUOTA 
value by the EXECUTOR BUFFER SIZE value. 

Unlike previous releases of DECnet-VAX, this PIPELINE 
QUOTA is not deducted from the user process's byte count 
quota. This change allows the system manager to set the 
process byte count quota to sensible values without concern 
for the nonpaged pool requirements of DECnet. DECnet's 
nonpaged pool usage with respect to the transmission over 
logical links is bounded by the product of the values of the 
PIPELINE QUOTA and MAXIMUM LINKS parameters. 

The following command sets a pipeline quota of 6000 bytes for 
the local node which is using a satellite link: 

NCP>SET EXECUTOR PIPELINE QUOTA 6000 
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The default value for PIPELINE QUOTA is currently 3000. If 
satellite communication is being used, it may be necessary to 
increase this value to 6000 or more in order to improve DECnet 
performance. 


3.9 Object Commands 

Use the SET OBJECT command to establish and modify the 
object parameters listed in Table 3-6. To remove any or all 
object parameters from the volatile database, use the CLEAR 
OBJECT command. 

Table 3-6 Object Parameters and Their Function 

Parameter Function 

Parameters 

Identifies object by number 

NUMBER number 

Identifies command procedure 
for starting the object 

FILE file-id 

Specifies connect privileges for 
user-level access control 

PRIVILEGES privilege-list 

Specifies optional default proxy 
login access control for the object 

PROXY option 

Specifies optional default access 
control for inbound connects 

ACCOUNT account 

PASSWORD password 

USER user-id 


3.9.1 DECnet-VAX Object Identification 

When defining or modifying object parameters, you must 
identify the name of the object. DECnet object names are 
descriptive alphanumeric strings of up to twelve characters in 
length. DECnet software also uses object numbers as unique 
object identifiers. Object numbers have a range of 1 to 255. 
Most user-defined images will have a 0 object type. However, 
a user program should have a nonzero number assigned when 
it provides a known service. You may define an object name of 
TASK in the configuration database to objects with a 0 object 
type if you provide additional required privileges or default 
inbound access control to the object. 
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3.9.2 


Generic objects such as FAL and NML have nonzero object 
numbers that are recognized throughout the network. User- 
defined images may have unique nonzero object numbers; 
numbers between 128 and 255 are reserved for this purpose. 
For a list of object numbers and their associated names, refer 
to the NCP section of the VAX/VMS Utilities Reference Volume. 
Unlike objects with a 0 object type, you must set each nonzero 
object in the configuration database. Use the NUMBER 
parameter to specify a unique object number for nonzero 
objects. For example: 

NCP>SET OBJECT F00 NUMBER 129 

Note that the object name may not be unique to the generic 
services specified. Only object numbers are unique across 
systems. For consistency, however, it is recommended that you 
use object names as they are normally referenced throughout 
the network. 

When NETACP receives a logical-link connect request message 
from a remote node, it translates the message into network 
connect block (NCB) format and delivers it to the destination 
object running on the local node. (Refer to Chapter 8 for a 
description of the NCB.) 


DECnet-VAX Command Procedure Identification 

For nonzero-numbered objects, the default name of this 
command file is SYS$SYSTEM:objectname.COM. Nonzero 
objects are identified in the logical link connect message 
only by object number. Therefore, there must be an entry 
in the object volatile database that enables NETACP to 
locate the object name using the object number as a key. 
When you install DECnet-VAX, nonzero object network- 
defined command procedures are entered by default in the 
SYS$SYSTEM directory, and NETACP knows about these 
command procedures. The supplied command files, named 
objectname.COM, include FAL, HLD, NML, EVL, DTR, MAIL, 
PHONE, and MIRROR. Except for those command procedures 
supplied by DIGITAL, you must create a command procedure 
for every object that can be started by an inbound connection 
request. You should name command procedures for nonzero 
objects objectname.COM and place them in SYS$SYSTEM. 
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For zero-numbered objects, the default name of this command 
file is SYS$LOGIN:objectname.COM. Zero objects are identified 
in the logical link connect message by object name. Therefore, 
there is no need for an entry in the object volatile database. 
You can, of course, specify an entry in the object database at 
any time. You would be required to include a separate entry 
if you desired special features such as default inbound access 
control information. 

In either case, you can override the rules for locating the 
command file by explicitly specifying a command procedure file 
in the SET OBJECT command. This file is associated with the 
object in the object volatile database, as shown in the following 
example: 

NCP>SET OBJECT FAL NUMBER 17 FILE SYS$MANAGER:TRIALFAL.COM 
NCP>SET OBJECT USERS NUMBER 0 FILE SYSlSYSTEM:USERS.COM 

This technique can be particularly useful for zero-numbered 
objects. The command file would then be found in the same 
place, regardless of which access control information you use. If 
you do not specify the FILE parameter, copies of the command 
file would have to exist in the SYS$LOGIN directory of every 
account in which the object may possibly run. 

Note: Because REMACP is started by a RUN command in 

RTTLOAD.COM, there is no REMACP.COM procedure 
to start the object, and the software does not create a 
REMACP.LOG file. 

You can also invoke an image directly to serve as a network 
object, rather than using a command procedure. To accomplish 
this, specify the object file name as objectname.EXE, as in the 
following example: 

NCP>SET OBJECT FAL NUMBER 17 FILE FAL.EXE 

The image should be placed in SYS$SYSTEM. This approach 
causes the object to be started up more quickly; it is useful in 
cases where no advantage is gained by invoking the image from 
a command procedure. The session log will appear as part of 
the NETSERVER.LOG file. 
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3.9.3 VAX PSI Objects 

Use the SET OBJECT command to identify each PSI object, its 
command procedure, and the account information to be used 
by calls coming in to the object from remote DTEs. 


3.9.3.1 VAX PSI Object Identification 

Each object must have a unique name. Object names are 
descriptive alphanumeric strings up to 8 characters in length, 
for example, OBJONE. 

Use the SET OBJECT command to identify the object. For 
example: 

NCP>SET OBJECT OBJONE ... 


3.9.3.2 VAX PSI Command Procedure Identification 

The system manager must create a command procedure for 
every object that can be accessed by a destination. Command 
procedures are named filename.COM. 

Use the FILE parameter to specify the command procedure for 
an object. For example: 

NCP>SET OBJECT OBJONE ... FILE STARTUP.COM ... 

The filename is associated with the object identification in the 
configuration database. To allow connections to an object, 
you must first create a command procedure in the default 
directory for the user account (either specified or defaulted) 
that the incoming call will log in to. The command procedure 
must also exist in the directory of every account in which the 
associated object may run. VAX PSI automatically creates a 
log file (filename.LOG) every time an incoming call causes an 
object's command file to be executed. This file is created in 
the default directory of the account. The log file is helpful for 
debugging your own network tasks when an error occurs. 

The command procedure will contain at least a RUN command 
for an image. It may also contain terminal assignments 
for debugging purposes (for example, DBG$INPUT and 
DBG$OUTPUT). There are no restrictions on the type of 
commands that you can have in this file. 
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3.9.3.3 VAX PSI Object Account Information 

The account information that is used by incoming calls from 
remote DTEs should be specified for each object. 

Use the ACCOUNT, PASSWORD, and USER parameters to 
specify the account information. For example: 

NCP>SET OBJECT OBJONE ... USER NET - 
_ PASSWORD NET ACCOUNT PAULS... 

The PASSWORD and USER parameters are mandatory. The 
ACCOUNT parameter is optional and, by default, no account is 
used. 


3.10 X.25/X.29 Server Module Commands 

The X25-SERVER and X29-SERVER module components 
handle incoming X.25 and X.29 calls from a PSDN. The server 
components contain records that identify destinations for 
incoming calls and associate with each destination parameters 
that determine whether the destination can handle an incoming 
call. The destination can be on a local DTE connected directly 
to a PSDN, or on a host node to which an X.25 multihost 
connector node is forwarding incoming calls. The server 
database also specifies the maximum number of incoming 
and outgoing circuits that each module (that is, all destinations 
for that particular module) can have, and specifies the state of 
the module. 


3.10.1 X25—SERVER and X29—SERVER Module 

Identification 

Use the SET MODULE X25-SERVER and SET MODULE 
X29-SERVER commands to identify the modules that handle 
incoming calls. The parameters for these two modules are the 
same. Use separate commands to specify the destination 
qualifier (DESTINATION), and the module parameters 
(MAXIMUM CIRCUITS, STATE, and COUNTER TIMER). 


3-105 





Managing and Monitoring the Network 


3.10.2 Destination Identification 

Each destination must have a unique name. Destination names 
are descriptive alphanumeric strings, from 1 to 16 characters 
in length. Use the DESTINATION qualifier to specify the 
destination name. For example: 

NCP>SET MODULE X25-SERVER DESTINATION JOE ... 

Associate any and all of the following parameters with each 
destination: SUBADDRESSES, GROUP, NUMBER, CALL 
MASK, CALL VALUE, PRIORITY, OBJECT, and NODE. The 
first five parameters (SUBADDRESSES, GROUP, NUMBER, 
CALL MASK, CALL VALUE) determine whether the incoming 
call can be handled. The PRIORITY parameter sets the priority 
of the destination, and the OBJECT parameter names the 
object activated when a destination accepts an incoming call. 
The NODE parameter identifies the host node on which the 
destination is located, if the call is received through a local X.25 
multihost connector node. 

The parameters are described below. 


3.10.2.1 DTE Subaddress Range 

Use the SUBADDRESSES parameter to specify a local DTE 
subaddress or a range of subaddresses for each destination. 

The destination uses this information to decide if it can handle 
incoming calls. 

In the command below, destination JOE will handle only 
incoming X.25 calls that specify local DTE subaddresses 35: 

NCP>SET MODULE X25-SERVER DESTINATION - 
_ JOE SUBADDRESSES 35... 

The following command, however, specifies that destination 
JOE will handle all incoming X.25 calls that specify a local DTE 
subaddress in the range 12 to 24 inclusive: 

NCP>SET MODULE X25-SERVER DESTINATION JOE- 
SUBADDRESSES 12-24... 

A subaddress is a decimal integer in the range 0 to 9999. 
Separate two subaddresses with a single hyphen to indicate a 
range. The second subaddress must always be greater than the 
first. 
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3.10.2.2 


3.10.2.3 


The SUBADDRESSES parameter is optional, and, by default, 
no subaddress range is used to determine if the destination can 
handle an incoming call. 


Group Identification 

Use the GROUP parameter to specify a closed user group 
(CUG) or bilateral closed user group (BCUG) name for each 
destination. The destination uses this information to decide if 
it can handle incoming calls. The following command indicates 
that destination JOE will handle only incoming X.25 calls that 
originate from a DTE that is a member of the closed user group 
ESECUG: 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
_ GROUP ESECUG ... 

The GROUP parameter is optional, and, by default, no group 
name is used to determine if the destination can handle an 
incoming call. 


Remote DTE Identification 

Use the NUMBER parameter to specify the remote DTE address 
that originated the call. The DTE address consists of 1 to 15 
digits. The destination uses this information to decide if it can 
handle incoming calls. 

As an example, the following command specifies that the 
destination JOE will handle only incoming X.25 calls that 
originate from the remote DTE with address 987321654: 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
_ NUMBER 987321654... 

The NUMBER parameter is optional and, by default, no remote 
DTE address is used to determine if the destination can handle 
an incoming call. 
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3.10.2.4 


User Data Field 

Optionally use the CALL MASK and CALL VALUE parameters 
to specify a call mask (to be applied to incoming call data before 
it is tested) and a call value (the string used to test incoming 
call data). If you specify these parameters, VAX PSI extracts the 
user data from the incoming call request and performs a logical 
AND operation between this data and the call mask. VAX PSI 
then compares the result of this operation with the call value; 
if the fields match, the destination can accept the incoming call. 
Note that the call mask and the call value you specify must be 
the same length. For example, the command below indicates 
that destination JOE will handle only incoming X.25 calls that 
contain value 11 in their user data fields: 

NCP>SET MODULE X25-SERVER DESTINATION JOE CALL VALUE 11 - 
_ CALL MASK FFFFFFFF ... 

The CCITT (Comite Consultatif International Telegraphique 
et Telephonique) recommends that you use a value of 01 for 
incoming X.29 calls. As an example, the command below 
indicates that destination JIM will handle only incoming X.29 
calls that contain 01 in their user data fields. 

NCP>SET MODULE X29-SERVER DESTINATION JIM CALL VALUE 01 - 
CALL MASK FF ... 

Specify strings of 2 to 32 hexadecimal digits for the two 
parameters. 

You can use these two parameters to further identify X.29 
calls when the terminal user first connects to the PAD (Packet 
Assembly/Disassembly Facility). To do so, specify a destination 
for the X29-SERVER that recognizes a value entered as call 
data when connecting to the PAD. For example, the following 
command indicates that the destination JANE will handle 
incoming X.29 calls that specified a call data value of A (41 is 
the hexadecimal value for A): 

NCP>SET MODULE X29-SERVER JANE CALL VALUE 0000000041 - 
CALL MASK 00000000FF ... 

The CALL MASK and CALL VALUE parameters are optional 
and, by default, no mask or value is used to determine if the 
destination can handle an incoming call. 
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3.10.2.5 Priority 

Use the PRIORITY parameter to specify the priority of each 
destination. If an incoming call can be accepted by more than 
one destination, the destination with the highest priority is 
used. For example, the command below assigns a priority of 3 
to destination JOE. 

NCP>SET MODULE X25-SERVER DESTINATION JOE PRIORITY 3... 

Specify a priority value in the range 0 to 255, where 255 is the 
highest priority. 

The PRIORITY parameter is mandatory if you specify more 
than one destination that could handle the same incoming call. 
Otherwise this parameter defaults to 0. 


3.10.2.6 Object Identification 

Use the OBJECT parameter to specify the name of the object 
that is activated when an incoming call arrives and is accepted 
by the destination. Specify the name as an id-string. If the 
object name is a string of digits, enclose the string in quotation 
marks. You must specify the object itself, using the SET 
OBJECT command (see Section 3.9.1). 

The command below specifies the object OBJONE. 

NCP>SET MODULE X25-SERVER DESTINATION JOE OBJECT OBJONE... 

The OBJECT parameter is mandatory when you specify a 
destination for the first time. 


3.10.2.7 Host Node Identification 

Use the NODE parameter with the DESTINATION qualifier 
to identify a host node on which the destination is located. 

A host node receives X.25 calls that have been forwarded 
by an X.25 connector node connected directly to a PSDN. If 
your local DECnet-VAX node is configured with VAX PSI 
software in multihost mode to serve as an X.25 connector 
node, you must specify the NODE parameter for each host 
destination. For example, if your local node is a connector 
node, use the command below to specify that incoming calls 
are to be forwarded to the indicated destination on host node 
THRUSH on the same Ethernet. 

NCP>SET MODULE X25-SERVER DESTINATION THRUSH - 
_ SUBADDRESSES 1-10 OBJECT 36 NODE THRUSH 
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Note that the host node THRUSH must be configured with PSI 
Access software to be associated with the X.25 connector node. 
The following command must be entered at node THRUSH 
to specify the destination of X.25 calls being forwarded by the 
X.25 connector node. 

NCP>SET MODULE X25-SERVER DESTINATION JOE - 
_ SUBADDRESSES 1-10 OBJECT OBJONE PRIORITY 1 


3.10.3 Maximum Circuits 

Use the MAXIMUM CIRCUITS parameter to specify the 
maximum number of circuits that the module (that is, all 
destinations) can handle. The command below enables the X.25 
SERVER module (the call handler for incoming X.25 calls) to 
handle a maximum of 32 circuits (incoming and outgoing calls) 
at any one time. 

NCP>SET MODULE X25-SERVER MAXIMUM CIRCUITS 32. . . 

The MAXIMUM CIRCUITS parameter is optional and, by 
default, the maximum is 255. 


3.10.4 Operational State of Server 

Use the STATE parameter to specify the operational state of the 
server module. There are three possible states: 

OFF Prevents use of the module and clears all existing virtual 
circuits 

ON Allows normal use of the module 

SHUT Prevents use of the module for any new activity, but 

allows existing virtual circuits to complete their operation 

The command below allows normal use of the module. 

NCP>SET MODULE X25-SERVER STATE ON ... 

The STATE parameter is optional and, by default, the state is 
ON. 

For a complete list of states and their transitions, refer to the 
NCP section in the VAX/VMS Utilities Reference Volume. 
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3.11 X.25 Access Module Commands 

The X25-ACCESS module contains the database needed to 
connect the local host node to a DECnet-VAX node serving 
as an X.25 multihost connector node that can access specific 
PSDNs on behalf of the host nodes. Both the host and the 
connector node must be on the same Ethernet. Your local 
host node must be a DECnet-VAX node on which VAX PSI 
Access software is installed. The X.25 connector node must be 
a VAX/VMS node with VAX PSI software in multihost mode 
installed. Refer to Chapter 5 for an example of the use of NCP 
commands to configure the X.25 connector and host nodes. 

Use the SET MODULE X25-ACCESS command to associate 
the name of the X.25 network you want to access with the 
name of the node serving as the connector to this network. You 
can optionally specify access control information for the link 
between your host node and the connector node. 


3.11.1 Network Identification in an X.25 Access Module 

Use the NETWORK qualifier in the SET MODULE X25- 
ACCESS command to identify the specific PSDN you want to 
access through the X.25 connector node; if you wish to access 
all PSDNs to which the connector node is connected, use the 
KNOWN NETWORKS qualifier. The network must be one to 
which DIGITAL supports connection (such as PSS). 

The command below identifies the network PSS to which the 
local DECnet-VAX node with VAX PSI Access software wants 
to have access. 

NCP>SET MODULE X25-ACCESS NETWORK PSS ... 

You must specify the NETWORK qualifier and must associate 
with it the NODE parameter. You can optionally specify access 
control information to be used by PSI Access software in 
connecting to the X.25 connector node. 
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3.11.2 X.25 Connector Node Identification 

Use the NODE parameter to identify the node that will provide 
connector or gateway services to the specified X.25 network. 

A DECnet-VAX node serving as an X.25 connector node must 
be configured with VAX PSI software in multihost mode. The 
connector node, also referred to as the target node, is the one 
with which the VAX PSI Access software on your local node 
establishes a DECnet link in order to transmit and receive X.25 
and X.29 calls. The following command identifies the node 
ROBIN as the one which will serve as the connector node to 
permit your local host node to access the network PSS: 

NCP>SET MODULE X25-ACCESS NETWORK PSS NODE ROBIN ... 

Both ROBIN and the local host node must be on the same 
Ethernet. ROBIN must be a DECnet-VAX node configured 
with VAX PSI software in multihost mode. ROBIN must 
be connected by an X.25 line to the network PSS. ROBIN 
must also contain an entry in its X.25 server module database 
indicating that the destinations of specific incoming X.25 calls 
are located on your host node (see Section 2.7). 


3.11.3 Access Control Parameters in an X.25 Access 
Module 

You have the option of specifying access control parameters 
to be used by the VAX PSI Access software on your local 
host node in establishing a link to the node serving as 
the X.25 connector. The access control parameters are the 
standard DECnet-VAX parameters: USER, PASSWORD, 
and ACCOUNT. The command below specifies the user 
identification PSI and password PSI the local node can use for 
an inbound connect when establishing a DECnet link with node 
ROBIN, the X.25 connector to the network PSS. 

NCP>SET MODULE X25-ACCESS NETWORK PSS NODE ROBIN - 
_ USER PSI PASSWORD PSI 
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3.12 Logging Commands 

In order to log events, you must turn logging on. (The 
DECnet-VAX default has all events cleared.) To do so, use 
the SET LOGGING command. Use the same command to 
modify any of the logging parameters. To remove any or 
all parameters from the volatile database, use the CLEAR 
LOGGING command. You must turn the logging state to OFF 
before attempting to use the CLEAR LOGGING command. 

Table 3-7 lists all logging parameters by function, and groups 
them according to operational categories. 


Table 3-7 Logging Parameters and Their Function 


Parameter 

Function 

Source-Related 

Parameters 

Sink-Related 

Parameters 

Identifies events 

EVENTS event-list 

KNOWN EVENTS 


Identifies source for 

events 

CIRCUIT circuit-id 

LINE line-id 

MODULE X25-ACCESS 
MODULE X25—PROTOCOL 
MODULE X25-SERVER 
MODULE X29-SERVER 

NODE node-id 


Determines location for 
logging events 

Assigns name to logging 
component 

SINK EXECUTOR 

SINK NODE node-id 

NAME {sink-name} 

Sets state to 
logging component 


STATE ( HOLD ) 
0FF 

( ON ) 


Source-related and sink-related parameters are mutually 
exclusive. Therefore, you cannot use parameters from both 
categories in a single command. Use the SET LOGGING 
EVENTS command to specify source-related events, and the 
SET LOGGING STATE command to specify sink-related events. 


For a summary of event class and types and information about 
the specific events that VAX/VMS will log, see the NCP section 
of the VAX/VMS Utilities Reference Volume. 
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The logging component is defined by the device or process that 
records the events released by the event logger. The logging 
component can be a LOGGING CONSOLE, LOGGING FILE, 
or LOGGING MONITOR. The LOGGING CONSOLE is a 
terminal or a file that receives events on the sink node in a 
format the user can read. A LOGGING FILE is a user-specified 
file on the sink node. The logging file component receives 
events in the standard DNA binary format. (Refer to the 
Network Management Functional Specification for a description of 
this format.) Instead of specifying the console and a file, you 
can specify a system- or user-supplied LOGGING MONITOR 
program to receive and process DNA format-specific events. 
This program could possibly receive event data and adapt user 
application network activity to reflect this data. 

Note: Because console logging uses normal VAX RMS file I/O, if a 
terminal is specified as a sink name, the terminal should not 
be used or allocated for any other purposes. For example, if 
a user should log in on such a terminal, events will be lost 
until the user logs out. 

If the logging sink is the LOGGING MONITOR and no 
sink name is specified, DECnet-VAX uses the Operator 
Communication (OPCOM) facility to display formatted event 
messages on all terminals enabled as NETWORK (using REPLY 
/ENABLE=NET), including the console (OPAO:). The format 
of event messages OPCOM displays is the same as for console 
logging; however, because of restrictions in the size of messages 
that OPCOM can display, some messages may be truncated 
slightly, and node, circuit, and line counters are not displayed 
at all. 

To identify the name of the logging device on the local node, 
use the NAME parameter. For example, if the device is a 
logging console file, the command below creates the file 
EVENTS.LOG in which formatted events will be logged. 

NCP>SET LOGGING CONSOLE NAME SYS$MANAGER:EVENTS.LOG 

Before setting the NAME parameter for a logging component, 
you must issue the command SET LOGGING STATE OFF for 
that component. 

Regardless of the logging component you use, parameter 
selection is the same. If you want to modify parameters for 
all logging on the network, then use the plural KNOWN 
LOGGING component when issuing the SET LOGGING 
command. 
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3.12.1 Event Identification 

Events are defined by class and type. You can specify the kinds 
of events to be logged by using the following event-list format: 


class.type 

class Identifies the DNA or system-specific layer to which the 
event pertains 

type Identifies a particular form of event, unique within an 
event class 

For example, to specify an event in the Routing layer, you 
would use event class 4. The event types for this class range 
from 0 to 14. Event type 0 indicates aged packet loss, event 
type 1 indicates unreachable node packet loss, and so forth. 
Refer to the NCP section of the VAX/VMS Utilities Reference 
Volume for a summary of events by class and type. Use the 
EVENTS parameter for the SET LOGGING command to 
specify those events to be logged. If you want to log all event 
classes and types, use the KNOWN EVENTS parameter. When 
defining the logging component, you must specify events to be 
logged. 

When providing an event list for the EVENTS parameter, you 
can specify only one class for each instance of this parameter. 
However, several formats can define event types for a particular 
class. You can specify a single event type, a range of types, or 
a combination of the two. The following table illustrates these 
formats. 


Event-list 

Meaning 

4.4 

Identifies event class 4, type 4 

4.5-7 

Identifies event class 4, types 5 through 7 

4.5,7-9,1 1 

Identifies event class 4, types 5, 7 through 9, 
and 11. Note that types must be specified in 
ascending order. 


The commands below illustrate invalid event lists. 

NCP>SET KNOWN LOGGING EVENTS 4.4,5.1 
NCP>SET KNOWN LOGGING EVENTS 4.7,3-4,1 
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The first example specifies more than one event class. The 
second example specifies event types in numerically descending, 
rather than ascending order. 

You can use the asterisk (*) wildcard character in an event list. 
This character can replace only an event type. The following 
example illustrates the correct use of wildcards: 

NCP>SET KNOWN LOGGING EVENTS 2.* 

This command identifies all event types for class 2 events. 

Two invalid uses of the wildcard character are shown below. 

NCP>SET LOGGING FILE EVENTS *.2-5 
NCP>SET LOGGING FILE EVENTS 4.2-* 

The first command specifies specific event types for all classes. 
Unless you use the KNOWN EVENTS parameter, you can only 
specify event type information for a single class. The second 
command uses a wildcard to specify a partial range of event 
types. The wildcard character denotes the entire range of event 
types for a given class. 


3.12.2 Identifying the Source for Events 

You can specify the particular source for which events apply, 
which can be either an area, a node, a module, a circuit, or 
a line. For example, to monitor network activity for circuit 
DMC-0 connected to the local node, use the command 

NCP>SET LOGGING CONSOLE CIRCUIT DMC-0 . . . 

Events that pertain to activity over this circuit will be logged 
at the console by the event logger. The same operation can be 
performed for any remote node. If no source is specified for a 
component, the event logger logs events for all circuits, lines, 
modules, and nodes known to the local node or DTE. 

Note that you can set only one source (a circuit, module, node, 
or line) as the source for events in a single command. 

The command CLEAR LOGGING KNOWN EVENTS clears 
only events that are not associated with any specific source. 

To remove an event associated with a specific source, use the 
CLEAR LOGGING command that specifies that source. 
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3.12.3 Identifying the Location for Logging Events 

Events can be logged either at the local node or a remote node. 
Use the SINK parameter to specify the location. For example, 
the following command routes all event information to the 
logging monitor program running on node DENVER: 

NCP>SET LOGGING MONITOR SINK NODE DENVER . . 

If you do not specify a location, the local node is the default. 


3.12.4 Controlling the* Operational State of Logging 

You can control the operational state of logging only for the 

local node. There are three logging states: 

HOLD Indicates that the sink is temporarily unavailable. Events 
destined for that location are queued. 

OFF Indicates that the sink is unavailable for receiving event 
information. Events will not be logged for that sink. 

ON Indicates that the sink is available for receiving event 

information. This is the normal operational state. 


Use the STATE parameter to specify the operational state 
of logging on the local node. The command below forces 
event information to be queued for all instances of the logging 
component on the local node. 

NCP>SET KNOWN LOGGING STATE HOLD 

Note that this control over logging does not affect the 
operational state of the node. It is recommended that you 
set the default state to ON in the permanent database. 

Note: The event logger object (number 26, name EVL) must be 

specified in the object database. If you experience difficulty 
with event logging, examine the event logger's own log file, 
SYS$MANAGER:EVL.LOG, for possible problems. 
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3.12.5 Event Logging Example 

The following example illustrates the use of NCP event logging 
commands. You may want to log events normally to OPCOM 
for each node in the network. In addition, you may want each 
node to transmit its events to a single node to be stored in a file. 
For the three nodes—DENVER, TRNTO, and BOSTON—you 
could issue the following commands at each node to accomplish 
this task. 

At nodes DENVER and BOSTON: 

NCP>SET LOGGING MONITOR STATE ON 

NCP>SET LOGGING MONITOR KNOWN EVENTS 

NCP>SET LOGGING MONITOR SINK NODE TRNTO KNOWN EVENTS 

At node TRNTO: 

NCP>SET LOGGING MONITOR STATE ON 

NCP>SET LOGGING MONITOR KNOWN EVENTS 

NCP>SET LOGGING CONSOLE NAME SYS$MANAGER:NETEVENTS.LOG 

NCP>SET LOGGING CONSOLE STATE ON 

NCP>SET LOGGING CONSOLE KNOWN EVENTS 

Events from all three nodes will be logged to all terminals 
enabled as NETWORK (through the DCL command, REPLY 
/ENABLE=NET) on node TRNTO. In addition, all local events 
will be logged locally to the file NETEVENTS.LOG on node 
TRNTO. Note that the transmitting node always specifies the 
destination of the event logger output and causes its locally 
generated events to be sent to the receiving sink node to be 
logged. 


3.13 Network Access Control Commands 

The system manager can specify NCP commands to provide for 
access control at the routing initialization level, at the system 
level during inbound logical link connections, and at the node 
level during inbound and outbound logical link connections. 
You can also use NCP commands to control proxy login access 
to individual accounts and network objects at the local node. 
This section indicates the NCP commands and parameters that 
can be specified for access control. Refer to Section 2.10 for a 
description of DECnet-VAX access control techniques. 
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3.13.1 Specifying Passwords for Routing initialization 

You can specify in your local configuration database transmit 
and receive passwords for each adjacent node. The transmit 
password is the one you send to the remote node and the 
receive password is the one you expect to receive from the 
remote node during the routing initialization sequence. Use 
the SET NODE command to specify these passwords. Each 
password can be one to eight alphanumeric characters in 
length. For example, the command below establishes transmit 
and receive passwords for the circuit(s) connecting the local 
node with node TRNTO. 

NCP>SET NODE TRNTO TRANSMIT PASSWORD VAX.NODE- 
_ RECEIVE PASSWORD VAX.NODE 

If the password contains one or more space characters, you 
must delimit it with quotation marks. 

To remove transmit and receive passwords from the volatile 
database, use the CLEAR NODE command, as shown in the 
example below. 

NCP>CLEAR NODE TRNTO RECEIVE PASSWORD TRANSMIT PASSWORD 

To provide for increased security when a remote node requests 
a connection over a point-to-point circuit, you can use the 
circuit parameter VERIFICATION INBOUND to prevent your 
node from revealing its routing initialization password while 
requiring a password from the remote node. 

When two nodes communicate over a point-to-point circuit, 
only one of the nodes can have the VERIFICATION INBOUND 
parameter set. The primary function of this parameter is to 
permit the system manager to restrict the nodes that can 
initialize over a particular circuit, especially over a dialup 
circuit. 

When a dialup node attempts to establish a dynamic connection 
with your node, the dynamic asynchronous circuit entry 
is supplied automatically to your configuration database. 

This entry includes the circuit parameter VERIFICATION 
INBOUND, which prevents your node from supplying a 
password to the node requesting a dynamic connection, but 
requires a password from the node dialing in. 


July 1985 
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Note that if VERIFICATION INBOUND is specified for a 
circuit, the node parameter INBOUND ROUTER or INBOUND 
ENDNODE, as appropriate, must be specified for the 
connecting node (see Section 3.13.3). This requirement applies 
to both dynamic and static asynchronous connections. 

If, on the other hand, you are a user on a node with a terminal 
line (such as a Micro VMS system) and you expect to form a 
dynamic asynchronous connection with another node, you 
should specify a transmit password in your node database. 

For example, if you are at node MYNODE and expect to 
form a dynamic connection with remote node VCLST1 on a 
VAXcluster, specify the following command to establish the 
transmit password for the dynamic circuit: 

NCP>SET NODE VCLST1 TRANSMIT PASSWORD H0MEN0DE1 

The remote node in a dynamic connection must specify the 
receive password it expects to receive from the local node. In 
the example, the system manager at remote node VCLST1 
specifies the following command to indicate the password 
expected from node MYNODE: 

NCP>SET NODE MYNODE RECEIVE PASSWORD H0MEN0DE1 


3.13.2 System-Level Access Control Commands 

You can use the SET NODE command to specify default 
privileged and nonprivileged access control strings for outbound 
logical link requests. Use the SET OBJECT command to specify 
privileges required to access certain objects during inbound 
logical link requests. You can also use the SET OBJECT 
command to specify a default access control string. For 
NCP commands to be executed at remote nodes, you can 
either supply explicit access control information in the node 
specification, as parameters in the command, or by default. 
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3.13.2.1 Establishing Default Privileged and Nonprivileged 
Accounts 

Use the SET NODE command to specify default access control 
information for connecting to remote nodes. If you have not 
specified explicit access control information in an outbound 
logical link request, this default information is sent with the 
request. For example, the command below specifies both 
privileged and nonprivileged user names and passwords for 
node DENVER: 

NCP>SET NODE DENVER- 

NONPRIVILEGED USER NETNONPRIV PASSWORD NONPRIV- 
PRIVILEGED USER NETPRIV PASSWORD PRIV 

You should specify default information for all remote nodes 
with which you want to have the option of using default access 
control. 


3.13.2.2 Specifying Privileges for Objects 

Use the SET OBJECT command with the PRIVILEGE parameter 
to specify those privileges that will cause the privileged user 
account to be used rather than the nonprivileged user account. 
The privilege list accompanying the parameter specifies those 
privileges required for all inbound connections to that object. 
For example, you may want to make the FAL object accessible 
to any network user, whereas you want to control access to the 
NML object. The following command specifies privileges for 
the NML object in this instance: 

NCP>SET OBJECT NML PRIVILEGES OPER 

You need not specify privileges for FAL because it requires only 
NETMBX and TMPMBX privileges. 


3.13.2.3 Setting Default Inbound Access Control Information 

Use the SET OBJECT command with the USER, ACCOUNT, 
and PASSWORD parameters to specify default inbound access 
control information. For example, the following command 
specifies default information that the local DECnet-VAX node 
can use for inbound connects from SLD: 

NCP>SET OBJECT HLD USER NETNONPRIV PASSWORD NONPRIV 
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3.13.2.4 Indicating Access Controls for Remote Command 
Execution 

Access control is used for remote NCP command execution. 
When you issue the SET EXECUTOR NODE and TELL 
commands, you can explicitly specify access control 
information, or you can default to information contained 
in the configuration database. 

Two formats exist to supply access control information explicitly 
for these commands. You can use either a standard VAX/VMS 
node specification (node"user password account"::) or the NCP 
parameters USER, ACCOUNT, or PASSWORD. For example, 
the following commands perform the same operation: 

NCP>SET EXECUTOR NODE TRNTO"GRAY MARY":: 

NCP>SET EXECUTOR NODE TRNTO USER GRAY PASSWORD MARY 

The same formats exist for the TELL command. Use of the 
standard VAX/VMS node specification format allows you to 
use a logical name as the node-id for these commands. It 
is possible to override access control in a logical name with 
explicit access control information in the command. 

You can also use access control information to cause NML to 
run under an account other than the default DECnet privileged 
account on the local node. Issue the following command for 
this purpose: 

NCP>SET EXECUTOR NODE TRNTO"user-id password" 


3.13.3 Node-Level Access Control Commands 

At the node level, you can specify access control commands 
that determine what connections can be made. If your node 
expects to receive dialup dynamic asynchronous connection 
requests, you can check the type of the dialup node before 
permitting the connection. 

The NCP commands SET NODE ACCESS and SET EXECUTOR 
DEFAULT ACCESS, when used together, allow you to partition 
your network to allow specific access for each node. For 
example, assume that there are 10 nodes in your network, 
named A through J. The executor is node A. Because most 
network traffic occurs between nodes A, B, and C, you could 
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use the following commands to allow unrestricted incoming 
and outgoing logical link connections among those nodes: 

NCP>SET NODE A ACCESS BOTH 
NCP>SET NODE B ACCESS BOTH 
NCP>SET NODE C ACCESS BOTH 

Next, assume that you want to allow local users to initiate 
connections to node D, but restrict connections from that node. 
Issue the command 

NCP>SET NODE D ACCESS OUTGOING 

Finally, assume that you want to allow incoming logical link 
connections from all other remote nodes (E through J), but 
restrict outgoing connections from the executor node. Issue the 
command 

NCP>SET EXECUTOR DEFAULT ACCESS INCOMING 

It is important to stress that the executor will check for a node 
ACCESS entry before it checks for the DEFAULT ACCESS 
entry. You should also remember that if the executor's state is 
set to OFF or SHUT, no logical links will be allowed. 

You can indicate the type of node that can connect to your 
node over a point-to-point circuit by specifying the INBOUND 
parameter in the SET NODE command. The INBOUND 
parameter permits you to check the type of a connecting 
node before you form a dynamic connection with the node. For 
example, if you expect the Micro VMS node MYNODE to initiate 
a dynamic connection by dialing in over a specific terminal line, 
you can specify the following in your node database: 

NCP>SET NODE MYNODE INBOUND ENDNODE 

If the node MYNODE dials in as a router, rather than as an 
end node, the dynamic connection is not formed. If you specify 
INBOUND ROUTER for the node and it dials in as an end 
node, the dynamic connection is permitted. 



Note that when the node parameter INBOUND is specified, 
the circuit parameter VERIFICATION INBOUND must also be 
set for the circuit over which the connection is to be made (see 
Section 3.13.1). If VERIFICATION INBOUND is not set for the 
circuit, the node parameter INBOUND is ignored. 
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3.13.4 Proxy Login Access Control Commands 

Access to individual accounts on the local node by proxy login 
is enabled by the DEFAULT PROXY setting in the executor 
database. The default setting of DEFAULT PROXY for each 
node permits both incoming and outgoing proxy access. This 
setting is the recommended option. You can, however, use the 
SET EXECUTOR command to modify the DEFAULT PROXY 
value at the local node. 

The default value of the DEFAULT PROXY entry in the 
executor database is equivalent to issuing the following 
command: 

NCP>SET EXECUTOR DEFAULT PROXY BOTH 

The system manager has the option of changing the default 
value, as in the following command, which prohibits any proxy 
login to or from the local node. 

NCP>SET EXECUTOR DEFAULT PROXY NONE 

To display the value of the DEFAULT PROXY entry for your 
node, use the command 

NCP>SH0W EXECUTOR CHARACTERISTICS 

If proxy login access is enabled at your node, the resultant 
display is 

Default proxy access = incoming and outgoing 


When proxy login access is enabled, the remote user can access 
a file accessible to the local account to which he has proxy 
access by using the node specification NODE:: in the standard 
VAX/VMS file specification. For example, a remote user can 
specify the following form of file specification to access a file on 
an account on node TRNTO to which he has proxy access: 

TRNTO::filename 


To override proxy login, the remote user with a proxy account 
on a node can specify NODE"":: in the file specification, 
causing the default DECnet account to be used, since explicit 
access control will be passed to the remote node. 
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Access to a network object through a proxy account is 
controlled by the PROXY parameter in the object database. 

By default, DECriet-VAX has set in the configuration database 
PROXY values for some network objects. These default values 
are the recommended values. To specify or modify the PROXY 
parameter for an object, use the SET or DEFINE OBJECT 
command with the PROXY parameter. In the following 
example, the outgoing proxy access option is set for the object 
MAIL. 

NCP>SET OBJECT MAIL PROXY OUTGOING 

To display the setting for the PROXY parameter in the 
database, use the SHOW OBJECT command with the 
CHARACTERISTICS parameter, as in the following command: 

NCP>SH0W KNOWN OBJECT CHARACTERISTICS 


The resulting display lists the database entries for each known 
object, indicating any proxy access that is enabled for the object. 
For object MAIL, the display is shown below. 


OBJECT = MAIL 
Number 
User id 
Password 
Proxy access 


* 27 

= NETNONPRIV 
= TREWQ 
= outgoing 


3.14 Monitoring the Network 

You can monitor network activity in one of two ways: by using 
the NCP command SHOW or by using the event logging facility 
and the SET LOGGING command. This section discusses the 
use of the SHOW and LIST commands. Refer to Section 2.9 for 
a discussion of events and event logging, and Section 3.12 for a 
description of the SET LOGGING command. 

NCP provides commands to display information about network 
components, regardless of whether they are defined in the 
volatile or permanent database. The NCP command SHOW 
displays information about components for the running 
network. The NCP command LIST performs a similar function, 
except that it lets you display and verify information in the 
permanent database. In many cases, this information will be a 
subset of the information displayed for the volatile database. 
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In general, the SHOW command allows you to monitor the 
operation of the running network. For example, whenever 
someone changes the state of a circuit, the configuration of 
the running network, in terms of reachable and unreachable 
nodes, may be changed as well. A circuit failure could have the 
same effect. NCP allows you to display the status of network 
circuits, lines, modules, and nodes, and thereby to detect such 
conditions. 

When issuing the SHOW and LIST commands, NCP allows you 
to select components and display types. You can choose among 
several display types, depending on the information you want. 
The display type determines the format and type of information 
that NCP displays. Display types are described below. 

CHARACTERISTICS Includes static information that is usually 
specified in the configuration database. 
Depending on the component, this 
information may include the identification 
of the local node and relevant routing 
parameters, the names and numbers 
of known network objects, and the 
identification and cost of circuits 
connected to the local node. For 
VAX PSI, the information may include 
identification of the local DTE and relevant 
parameters; packet size, window size, and 
other network parameter values; device 
identification; and timer values. 

STATUS Includes dynamic information that usually 

reflects network operations for the running 
network. Depending on the component, 
this information may include the local node 
and its operational state, reachable and 
unreachable nodes and their operational 
states, and circuits with their operational 
states. For VAX PSI, the information 
reflects the operation of the running 
VAX PSI software. Depending on the 
component, this may include identification 
of the line with its operational state. 
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SUMMARY 


EVENTS 


COUNTERS 


Includes only the most useful information 
derived from both static and dynamic 
sources. This information is usually an 
abbreviated list of information provided 
for both the CHARACTERISTICS and 
STATUS display types. For VAX PSI, it is 
usually an abbreviated list of information 
provided for the STATUS display type. 
Includes information about events 
currently being logged for the logging 
component. This display type is valid 
only for the SHOW LOGGING and LIST 
LOGGING commands. 

Provides counter information for circuits, 
lines, modules, and nodes, including the 
local node. Counters are discussed in the 
sections of this chapter that describe the 
circuit, line, module, and node commands. 


If you do not specify a display type when issuing a SHOW or 
LIST command, SUMMARY is the default. Examples of these 
display types and their formats are given in the NCP section of 
the VAX/VMS Utilities Reference Volume. 

When you display information about network components, you 
can use either the singular or plural form of the component, as 
shown in the following example: 

NCP>SH0W NODE BOSTON CHARACTERISTICS 


NCP>SHOW KNOWN NODES CHARACTERISTICS 


For several components, there is a second form of the plural. 
This form is the ACTIVE keyword. Whereas the KNOWN 
keyword displays information for components available to the 
local node, the ACTIVE keyword displays information for all 
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active components—that is, components whose state is other 
than OFF. Use the ACTIVE keyword with circuit, line, node, 
and logging components. For example, the following command 
displays the characteristics for all active nodes in the network: 

NCP>SH0W ACTIVE NODES CHARACTERISTICS 


The keyword ADJACENT is also used as a plural in the SHOW 
NODE command, as in the following 

NCP>SH0W ADJACENT NODES STATUS 

All NCP display commands optionally allow you to direct 
the information displayed to a user-specified output file. For 
example: 

NCP>SH0W KNOWN LOGGING SUMMARY TO SYS$MANAGER:NET.LOG 

This command creates the file SYS$MANAGER:NET.LOG 
containing summary information of all known logging for the 
running network. The default file type is LIS. If the specified 
file already exists, NCP appends the display information to that 
file. If you do not specify an output file, SYS$OUTPUT is the 
default. 

NML must have the BYPASS privilege to display passwords for 
the SHOW or LIST commands; if it does not, no information 
will appear if you use SHOW, and the "no access rights" 
message will appear if you use LIST. 
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DECnet-VAX can act as the host node in performing the 

following services for unattended systems: 

• Downline loading of an unattended system* transferring a 
copy of an operating system file image from a VAX/VMS 
node to a target node. 

• Upline dump of memory from an unattended system: 
transferring a copy of a memory image from an unattended 
target node to your VAX/VMS node. 

• Downline loading of an RSX-11S task from a VAX/VMS 
node. 

• Connecting to a remote console: permitting a VAX/VMS 
terminal to act as the console for certain unattended systems, 
such as the DIGITAL Ethernet Communications Server 
running Router Server Software. 

These operations are described in this chapter. 


4.1 Loading Unattended Systems Downline 

DECnet-VAX allows you to load an unattended system down¬ 
line. Downline loading involves transferring a copy of the file 
image of a remote node's operating system from a VAX/VMS 
node to the unattended target node. For example, DECnet-VAX 
permits you to load an RSX-11S operating system file image 
from your VAX/VMS node downline to a target node. Down¬ 
line loading can be initiated by a VAX/VMS operator or by the 
target node. Both procedures are discussed in this section. 

To understand downline loading, it helps to distinguish the 
nodes involved in the loading sequence. In the node descrip¬ 
tions below, the command node and the executor node can be 
the same or different nodes, but cannot be the target node. 
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4.1.1 


• Command node. An operator-initiated downline load 
request originates at the command node. You use either the 
NCP command LOAD or TRIGGER to initiate this request. 

• Executor node. The executor node actually performs a 
downline load or trigger operation. It must be adjacent to 
the target node because it uses circuit-level access. 

• Target node. The target node receives the bootstrap loaders 
and the system image file. 


Downline System Load Operation 

Downline loading is initiated in one of two ways: either an 
operator initiates the operation with the NCP command LOAD 
or TRIGGER, or the target node initiates the operation by trig¬ 
gering its bootstrap ROM and sending a program load request 
to the executor node. With an operator-initiated load, the ex¬ 
ecutor starts the operation by sending either a trigger message 
(if necessary) or a load file to the target node. Essentially, the 
trigger message provides the restart capability for an unattended 
target node. Once the target node is triggered, it will then load 
itself in whatever manner its primary loader is programmed to 
operate. This could include requesting a downline load from 
either the executor that just triggered it or another adjacent 
node; the target node could also load itself from its own mass 
storage device. 

DECnet uses the maintenance operation protocol (MOP) to 
perform a downline load operation. MOP is the protocol 
used by the network management portion of DNA to perform 
maintenance functions such as circuit testing, triggering, upline 
dumping, and downline loading. Once triggered, the target 
node usually sends MOP program request messages requesting 
a program to be loaded. 

If the load is target initiated, DECnet-VAX detects MOP mes¬ 
sages coming over the circuit and sets the circuit's state to 
AUTOSERVICE. NML uses the MOM subprocess named 
MOM_circuit-id_process-number (for example, 
MOM_UNA-O_l) to perform the load. NML, through that 
subprocess, searches the volatile database for a node entry with 
a service circuit that matches the circuit over which the message 
was received, and, if it is an Ethernet circuit, an Ethernet ad¬ 
dress that matches the Ethernet source address from which the 
message was received. NML then performs the load operation. 
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In this manner, NML provides the control mechanism for the 
loading process. Figure 4-1 illustrates this loading process. 

Figure 4-1 Target-Initiated Downline Load 


BOSTON 

(EXECUTOR NODE) 



NYC 

(TARGET NODE) 


If the target on an Ethernet circuit does not have a specific 
node from which to request a program load (for example, if 
the target's loading node crashes, or if the load is initiated by 
means of the BOOT button on the target), the target proceeds 
as follows: 
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1 The target node sends a program load request message to 
the Ethernet load assistance multicast address AB-00-00- 
01-00-00 (described in Section 3.3.3.4). This message is a 
request for any node on that Ethernet to perform the load. 

2 The nodes on the Ethernet whose circuits are enabled to 
perform service functions check their own databases for 
a remote node entry whose Ethernet hardware address 
matches that of the target node to determine if they can 
load the target downline. If so, they send to the target the 
secondary loader (if the target is requesting the secondary 
loader), or a message volunteering to do the load (if the 
target is requesting the tertiary loader or operating system). 

3 The target choses the node responding first to continue the 
loading sequence. It does not send a message to any other 
node. The loading sequence continues normally from there. 

Conversely, an operator-initiated load using NCP directly re¬ 
quests NML to perform the load operation. The target node's 
primary bootstrap may or may not have to be triggered de¬ 
pending on the state of the target. The target node is triggered 
primarily to put it into a known state and to force it to supply 
program request information. Figure 4-2 illustrates the loading 
process. 

Use the NCP command LOAD or TRIGGER to perform an 
operator-initiated downline load. The TRIGGER command 
allows you to directly trigger the remote node's bootstrap ROM, 
which causes the target node to send its host a request for a 
load operation. The programs to be loaded may come from a 
local disk file on the target node, another adjacent node, or the 
executor node. 

Note that the TRIGGER command may or may not initiate a 
downline load. One of the functions of this command is to 
simulate the operation that occurs when the BOOT button on 
the target node is pushed. A bootstrap operation from the local 
disk may result. 

When you use the LOAD command, the executor node pro¬ 
ceeds with the load operation according to the options specified 
in the initial load request. Any required information that has 
been defaulted is obtained from the volatile database. With this 
information, the executor is thereby able to control the load 
sequence. 
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Figure 4-2 Operator-Initiated Downline Load 


NCP Commands: 


TRNTO 

(COMMAND NODE) NCP>SET EXECUTOR NODE BOSTON 



NYC 

(TARGET NODE) 


ZK-549-81 


Section 4.1.2 describes the TRIGGER and LOAD commands, 
their parameters, and examples of their use. 
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4.1.1.1 Load Sequence 

The load sequence is the same, regardless of whether the 
request was initiated by the operator or the target node. The 
first program to run at the target node is the primary loader. 
Typically, this program is either executed directly from the 
target node's bootstrap ROM, or it is in the microcode of the 
load device (DMC, DMR, DMP, DMV, UNA, or QNA). Once 
the target node's primary loader is triggered, the target node 
sends a message to the executor node requesting a program 
load. This program may come directly from the executor or 
from a remote node. Usually, the primary loader requests 
a secondary loader program, which, in turn, may request a 
tertiary loader. The final program to be loaded is the operating 
system. In this sequence, each program requests the next one 
until the operating system is loaded. 

The secondary loader is small and is always sent as a single 
message. The tertiary loader and the operating system are 
larger and are sent in segments. For both of these latter two, 
the last segment is followed by a "PARAMETER LOAD WITH 
TRANSFER ADDRESS" message, which supplies the start 
address of the image just loaded and contains extra values for 
the node identification and the host identification. 


4.1.1.2 Load Requirements 

Prior to attempting a downline load operation, you must ensure 

that nodes, lines, and circuits meet the following requirements: 

• The target node must be connected directly to the executor 
node. The executor node provides the line- and circuit-level 
access. 

• The primary loader must either be a cooperating program in 
the target or in the microcode of the target's device (DMC, 
DMR, DMP, DMV, or UNA). The downline load operation 
usually involves loading a series of bootstraps, each of 
which requests the next program until the operating system 
itself is loaded. 

• The executor must have access to the load files. The location 
of the files can be either specified in the load request or 
defaulted to in the volatile database. Remote files are 
obtained through remote file access operations. (Refer to the 
examples in Section 4.1.2.4.) 

• The target node must be able to recognize the trigger 
operation or must be triggered manually. 
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• The circuit involved in the load operation must be enabled 
to perform service functions. It must also be in the ON or 
SERVICE state; a multiaccess Ethernet circuit must be in 
the ON state. For example, the following command readies 
circuit DMC--0 for downline loading node BANGOR in our 
network example: 

NCP>SET CIRCUIT DMC-0 SERVICE ENABLED STATE ON 

• You must turn the line to ON and specify a service timer 
for the line. This timer sets the MOP timeout constant 
for retransmission if necessary. This is the method by 
which MOP handles error recovery. The default for the 
service timer is 4000 milliseconds. In the example below, 
the command sets the retransmission frequency to 5000 
milliseconds and turns on line DMC-0. 

NCP>SET LINE DMC-0 SERVICE TIMER 5000 STATE ON 

Refer to the Maintenance Operation Protocol Functional Specifica¬ 
tion for a complete description of MOP error recovery. 


4.1.2 Operator-Initiated Downline Load Parameters 

The most convenient method of downline loading involves set¬ 
ting default information in the volatile database. The operator 
can use the NCP command SET NODE to establish default 
information for the target node in the volatile database. These 
default parameters are also used for target-initiated downline 
loads, though the MOP program load message can override 
some of the defaults. (This default method is discussed later 
in this chapter.) Alternatively, you can override the default by 
specifying several parameters for the NCP commands TRIGGER 
or LOAD. This section describes each parameter and illustrates 
its use. 


4.1.2.1 TRIGGER Command 

The TRIGGER command triggers the bootstrap mechanism of a 
target node, which causes the node to request a downline load. 
Because the system that is being booted is not necessarily a 
fully functional network node, the operation must be performed 
over a specific circuit. To bring up the system at the target 
node, use either the TRIGGER NODE or TRIGGER VIA com¬ 
mand. If you use the TRIGGER NODE command and do not 
specify a loading circuit, the executor node obtains the circuit 
identification associated with the target node from its volatile 
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database. If you use the TRIGGER VIA command, which in¬ 
dicates the loading circuit but not the node identification, the 
executor node uses the default target node identification in its 
volatile database. To identify the target node in the volatile 
database, specify the SET NODE command with the appropri¬ 
ate SERVICE CIRCUIT parameter, which establishes the circuit 
to be used for loading. 

The command below triggers node BANGOR in the network 
example. 

NCP>TRIGGER NODE BANGOR VIA DMC-0 

Note that this command specifies a DDCMP circuit over which 
the operation is to take place. Figure 4-3 also illustrates the 
use of the TRIGGER command for downline loading over a 
DDCMP circuit in the network example. 

If downline loading is to occur over an Ethernet circuit, the 
executor node uses the Ethernet physical address of the target 
node to distinguish it from other adjacent nodes on the same 
Ethernet circuit. The PHYSICAL ADDRESS parameter for the 
target node is required in the TRIGGER VIA command and 
optional in the TRIGGER NODE command. 

If you do not specify an Ethernet physical address in the 
TRIGGER NODE command, DECnet-VAX derives one from the 
target's node number and attempts to trigger the node. A target 
node that is running DECnet software has set its own Ethernet 
physical address and recognizes the address; otherwise, the 
target node recognizes only the Ethernet hardware address set 
by the manufacturer. If unsuccessful in triggering the node, 
DECnet-VAX attempts to use the Ethernet hardware address 
of the target node from the volatile database to trigger it. You 
can set in the volatile database the Ethernet hardware address 
originally assigned to the target node's DEUNA or DEQNA 
controller by specifying the HARDWARE ADDRESS parameter 
in the SET NODE command. (Refer to Section 3.3.3 for a 
description of Ethernet addressing.) 

Figure 4-4 illustrates the use of the TRIGGER NODE command 
for downline loading a target node over Ethernet circuit UNA-0. 
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Figure 4-3 Operator-Initiated Downline Load Over DDCMP 
Circuit (TRIGGER Command) 


BANGOR 

(Target Node) 


DENVER 



BOSTON 

(Executor Node) 


NYC 


NCP Commands: 


NCP>SET EXECUTOR NODE BOSTON 
NCP>SET LINE DMC-1 STATE ON 
NCP>SET CIRCUIT DMC-1 STATE ON 

NCP>TRIGGER NODE BANGOR SERVICE PASSWORD FEFEFEFE 

ZK-1867-84 
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Figure 4-4 Operator-Initiated Downline Load Over Ethernet 
Circuit (TRIGGER Command) 


UNA-0 


I- 1 



BOSTON 

(EXECUTOR NODE) 


TARGET 

(TARGET NODE) 


NCP Commands: 

NCP>SET LINE UNA-0 STATE ON 
NCP> SET CIRCUIT UNA-0 STATE ON 

NCP>TRIGGER NODE TARGET PHYSICAL ADDRESS AA-00-04-00-CB-04 VIA UNA-0 

ZK-1213-82 


When you use the TRIGGER command, it may not always 
be obvious how the system load is performed. Essentially, 
this command provides the trigger message that controls the 
restart capability for an unattended target node. Once the target 
node is triggered, it will then load itself in whatever manner 
its primary loader is programmed to operate. The target node 
could request a downline load from either the executor that just 
triggered it or another adjacent node, or the target node could 
load itself from its own mass storage device. 

One parameter that you can specify for the TRIGGER command 
is SERVICE PASSWORD. This parameter supplies a boot 
password, which may be required by the target node (see 
Section 4.1.2.9). If you do not specify this parameter, a default 
value from the volatile database is used. Use the SET NODE 
command to establish a default value for this parameter in the 
volatile database. If no value is set in the volatile database, the 
value is 0. 
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4.1.2.2 LOAD Command 

Use the LOAD NODE and LOAD VIA commands to load 
software downline to a target node. For example, the following 
command loads node BANGOR: 

NCP>LOAD NODE BANGOR 

The LOAD NODE command requires the identification of the 
service circuit over which to perform the load operation. If you 
do not explicitly specify a service circuit in this command, the 
executor node uses the SERVICE CIRCUIT from the volatile 
database entry for the target node. You must use the SET 
NODE command to include the SERVICE CIRCUIT entry in the 
volatile database. Alternatively, you can explicitly include the 
circuit in the command LOAD NODE BANGOR VIA DMC-0. 

You could also use the LOAD VIA command to specify the 
circuit over which to perform a downline load. For example, to 
load using circuit DMC-0 connected to the executor node, issue 
the command 

NCP>LOAD VIA DMC-0 

The executor node obtains the rest of the necessary information 
from its volatile database. The LOAD NODE and LOAD VIA 
commands will work only if the target node can be triggered by 
the executor or if the target has been triggered locally. 

If the loading circuit is a multiaccess Ethernet circuit, the 
executor node uses the Ethernet physical address of the target 
node to differentiate the node from other adjacent nodes on the 
same Ethernet. The PHYSICAL ADDRESS parameter must be 
specified in the LOAD VIA command (which does not identify 
the target node) and can optionally be specified in the LOAD 
NODE command. 

If you do not specify the PHYSICAL ADDRESS parameter in 
the LOAD NODE command, DECnet-VAX derives the Ethernet 
physical address from the target node number and attempts 
to load the target node. A target node that is running DECnet 
software has set its own Ethernet physical address and will 
recognize this address; otherwise, the target node will recognize 
only the Ethernet hardware address set by the manufacturer. 

If unsuccessful in loading the node, the executor node will 
attempt the load using the Ethernet hardware address of the 
target node from the volatile database. You can set in the 
volatile database the Ethernet hardware address originally 
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assigned to the target node's DEUNA or DEQNA controller, by 
specifying the HARDWARE ADDRESS parameter in the SET 
NODE command. (Refer to Section 3.3.3.4 for a description of 
Ethernet addressing.) 

Figure 4-5 illustrates the use of the LOAD command for 
downline loading over Ethernet circuit UNA-0. 


Figure 4-5 Operator-Initiated Downline Load Over Ethernet 
Circuit (LOAD Command) 


UNA-0 


f - ! 



BOSTON TARGET 

(EXECUTOR NODE) (TARGET NODE) 


NCP Commands: 

NCP>SET NODE TARGET SERVICE CIRCUIT UNA-0 
NCP>SET LINE UNA-0 STATE ON 
NCP>SET CIRCUIT UNA-0 STATE ON 

NCP>LOAD NODE TARGET PHYSICAL ADDRESS AA-00-04-00-CB-04 

ZK-1214-82 


If you choose to override the default parameters for the LOAD 
commands, you can control the following aspects of the load 
sequence: 

• The host node that the target node is to use once the target 
comes up 

HOST node-id 


The identification of the load file 
FROM file-id 
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• The identification of the loader programs 

SECONDARY LOADER file-id 
TERTIARY LOADER file-id 

• The software type to be loaded downline first 

SOFTWARE TYPE software-type 

The software-type can be any of the following: 

SECONDARY LOADER 
TERTIARY LOADER 
SYSTEM 

If the software-type is not specified in the first MOP pro¬ 
gram request, the NCP command, or the volatile database, 
the default is SECONDARY LOADER. 

• The identification of the CPU type and the corresponding 
software identification 

CPU cpu-type 

SOFTWARE IDENTIFICATION software-id 

• The identification of the target node's line device type that 
is to handle service operations 

SERVICE DEVICE device-type 

• The identification of the service password for triggering the 
target node's bootstrap mechanism 

SERVICE PASSWORD hex-password 

When issuing the LOAD NODE and LOAD VIA commands, 
you can specify any or all of the parameters listed above. Any 
parameter not specified in the command defaults to whatever 
information is specified in the volatile database. Use the SET 
NODE command to establish default information for the target 
node's parameters in the volatile database. 
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4.1.2.3 Host Identification 

At the end of the load sequence, the target receives a message 
with the name of the host and places that name in its volatile 
database. The target can then use the HOST node-id for 
downline task loading applications. The host may be the 
executor node or any other reachable node except for the target 
itself. Use the SET NODE command to specify a default host 
node where the target will find the files used to load tasks 
downline. For example, the command below sets the host to 
node NYC once node BANGOR comes up as a network node 
(if BANGOR has the necessary DECnet software): 

NCP>SET NODE BANGOR HOST NYC 

If the host is unspecified, the executor serves as the default 
host. You can override any default information by using the 
HOST parameter for the LOAD command. 


4.1.2.4 Load File Identification 

The load files are those files to be loaded downline to the target 
node. These files may consist of a secondary loader, a tertiary 
loader, and an operating system image. You can specify default 
load file names in the volatile database with the SET NODE 
command. Load files default to SYS$SYSTEM:filename.SYS. If 
the files are on another node, specify node-id:: at the beginning 
of the file specification. 

Figure 4-6 illustrates the use of the LOAD NODE command for 
loading a target node over a DDCMP circuit. 

If the secondary and tertiary file names are not included in the 
LOAD command or as entries in the volatile database for the 
target node, the load files are selected according to the service 
device type on the target system, not by the device type on the 
executor. The default secondary and tertiary loader files are as 
listed in Table 4-1. The DECnet-llS kit includes the files listed 
in Table 4-1. 

If load file names are not specified in the target's load request, 
the NCP command LOAD or the volatile database, NML will 
provide them by concatenating the service device with the 
prefix SEC or TER. For example, if the service device is a DMC, 
NML uses the file names SECDMC.SYS and TERDMC.SYS. 
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Figure 4-6 Operator-Initiated Downline Load Over DDCMP 
Circuit (LOAD Command) 


BANGOR 


DENVER 


(Target Node) 



NYC 


NCP Commands: 


NCP>SET EXECUTOR NODE BOSTON 
NCP>SET LINE DMC-1 STATE ON 
NCP>SET CIRCUIT DMC-1 STATE ON 

NCP> LOAD NODE BANGOR FROM NYC::SYS$SYSTEM:RSX11 S.SYS 

ZK-1868-84 
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Table 4-1 Default Loader Files by Target Device Type 


Device Type 

Secondary Loader 

Tertiary Loader 

DPI 1 

SECDP.SYS 

TERDP.SYS 

DL1 1 

SECDL.SYS 

TERDL.SYS 

DU1 1 

SECDU.SYS 

TERDU.SYS 

DQ1 1 

SECDQ.SYS 

TERDQ.SYS 

DUP1 1 

SECDUP.SYS 

TERDUP.SYS 

DMC1 1 

SECDMC.SYS 

TERDMC.SYS 

DU VI 1 

SECDUV.SYS 

TERDUV.SYS 

DPV 

SECDPV.SYS 

TERDPV.SYS 

DA 

SECDA.SYS 

TERDA.SYS 

DMP 

SECDMP.SYS 

TERDMP.SYS 

DM VI 1 

SECDMV.SYS 

TERDMV.SYS 

QNA 

SECQNA.SYS 

TERQNA.SYS 

UNA 

SECUNA.SYS 

TERUNA.SYS 


If, however, you include the secondary and tertiary file names 
as entries in the volatile database for the target node, they can 
override the default loader files described above. By using the 
SET NODE command, you can select your own special load 
files for a particular target node. If you do not specify the 
load files, you can change the service device type at the target 
node without changing the target node's database entry at the 
executor node. 

The system image file entry in the host node's volatile database 
serves as the default file name for the operating system to be 
downline loaded. This file name is required when the target 
node is to be loaded, but it can be supplied by the LOAD 
command. 


4.1.2.5 Software Type 

Along with identifying load files, you can specify the file types 
to be used for the initial load. For example, if the target node 
is already running a secondary loader program, you may only 
want to load the tertiary loader and operating system downline. 
To do this, you use the SOFTWARE TYPE parameter with the 
LOAD command. For example, to load a tertiary loader file. 
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which in turn would load the operating system image, you 
would use the command below. 

NCP>LOAD NODE BANGOR SOFTWARE TYPE TERTIARY LOADER 

Use the SET NODE command to specify default software type 
information for the target node entry in the volatile database. 
If no software type information is specified in the volatile 
database, the default type is the secondary loader. 


4.1.2.6 CPU and Software Identification 

The software identification is the default program name of the 
operating system to be loaded downline. Use the SOFTWARE 
IDENTIFICATION parameter to specify a software-id of up 
to 16 alphanumeric characters. For example, in the following 
command the CPU parameter specifies the default processor 
type to be loaded downline: 

NCP>SET NODE BANGOR SOFTWARE IDENTIFICATION RSX_11S_V3.2 


4.1.2.7 Service Device Identification 

The service device is the controller on the target node end of a 
service circuit. The service device handles downline loading in 
a variety of ways, depending on the device used. In particular, 
this device influences the type of files suitable for downline 
loading. Default load file names are selected according to the 
service device for the target node. 

The SERVICE DEVICE parameter identifies the default sec¬ 
ondary and tertiary loaders for the load operation. This pa¬ 
rameter is required for any downline load if the secondary and 
tertiary load files are not specified in the volatile database of the 
target node. SERVICE DEVICE is also required if the program 
load requests from the target node do not specify the secondary 
and tertiary load file names. Use the SET NODE command 
to specify the service device type in the volatile database. For 
example, the command below identifies the service device as a 
DMC device controller. 

NCP>SET NODE BANGOR SERVICE DEVICE DMC 

By using the SERVICE DEVICE parameter for the LOAD com¬ 
mand, you can override the service device default information. 
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4.1.2.8 Service Circuit Identification 

In terms of the executor, the service circuit is a circuit connect¬ 
ing the executor node with an adjacent target node. When you 
issue the LOAD and TRIGGER commands, you must specify 
or default to a circuit over which the load operation is to take 
place. Use the VIA parameter to explicitly identify the circuit 
when issuing these commands. If specifying an Ethernet circuit 
in the LOAD VIA command, you must include the PHYSICAL 
ADDRESS parameter in the command. 

If you do not specify a circuit, this information defaults to the 
circuit specified in the target node's volatile database. To set 
a service circuit in the volatile database, use the SET NODE 
command. 


4.1.2.9 Service Passwords 

When defining nodes for downline loading in the local volatile 
database, the system manager can specify a default service pass¬ 
word. This password may be required to trigger the primary 
bootstrap mechanism on the target node. If a user issues a 
LOAD or TRIGGER command without a service password, then 
this default parameter will be used if the target node requires 
one. To set a service password in the volatile database, use the 
SET NODE command. This password must be a hexadecimal 
number in the following ranges: 

• For DMC/DMR/DMP/DMV, the range is 0 to FFFFFFFF 

• For UNA/QNA, the range is 0 to FFFFFFFFFFFFFFFF 

For example, to load node BANGOR on circuit DMC-1: 

NCP>SET NODE BANGOR SERVICE PASSWORD FEFEFEFE 
NCP>L0AD NODE BANGOR 


4.1.2.10 Diagnostic File 

Once the target node is loaded downline, it can request di¬ 
agnostics. Use the DIAGNOSTIC FILE parameter in the SET 
NODE command to identify in the volatile database the diag¬ 
nostics file that the target node can read. 
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4.2 Dumping Memory Upline From an Unattended System 

As a DECnet-VAX system manager, you can include certain 
SET NODE parameters in the volatile database that will allow 
an adjacent unattended node to dump its memory into a file 
on your VAX/VMS system. This procedure is referred to as 
upline dumping. It is a valuable tool for crash analysis; that 
is, programmers can analyze the dump file and determine why 
the unattended system failed. When an unattended system that 
selected the appropriate support at system generation detects 
an impending system failure, that system will request an upline 
dump; for example, an RSX-11S system may request an upline 
memory dump to a VAX/VMS system. 

For upline dump operations, the local VAX/VMS node is 
referred to as the executor and the adjacent unattended node as 
the slave. 



4.2.1 



Upline Dump Procedures 

This section describes the procedures for an upline dump initi¬ 
ated by a slave node. DECnet uses the maintenance operation 
protocol (MOP) to perform an upline dump operation. MOP 
is a subset of the DIGITAL Data Communications Message 
Protocol (DDCMP) that sends messages used for circuit testing, 
triggering, downline loading, and upline dumping. Refer to 
the Maintenance Operation Protocol Functional Specification for a 
more complete discussion. 

There are four steps involved in the upline dump process. The 
actual dump takes place by repeating step 3. 

1 When a slave node senses a system failure, it sends a 
memory dump request to the VAX/VMS host node, or, 
on Ethernet, to a dump assistance multicast address if an 
Ethernet host is not available (see below). The request is a 
MOP request dump service message. This message might 
contain information about the slave's memory size (DUMP 
COUNT) and the upline dump device type at the slave. 

2 If the message from the slave includes a DUMP COUNT 
value, the host node uses it. Otherwise, the host node 
checks the slave node's entry in its volatile database for 
the DUMP COUNT, the target address from which to start 
dumping (DUMP ADDRESS) and the file where the memory 
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will be stored (DUMP FILE) for the slave. (If no entry exists 
for DUMP ADDRESS, the value defaults to 0.) The host 
node, which can now be considered the executor, sends a 
MOP request memory dump message to the slave with the 
starting address and buffer size values. 

3 Using the values it received from the executor, the slave 
returns the requested block of memory in a MOP memory 
dump data message. The executor receives the block of 
dump data, places it in the DUMP FILE, increments the 
DUMP ADDRESS by the number of locations sent, and 
sends another request memory dump message to the slave. 
This sequence is repeated until the amount of memory 
dumped matches the DUMP COUNT value. The executor 
then sends a MOP Dump Complete message to the target. 

4 Once the upline dump is completed, the executor node 
automatically attempts to downline load the slave system. It 
initiates the downline load by sending a TRIGGER message 
to the slave (see Section 4.1). 

Figure 4-7 illustrates the upline dump procedure. 

If the target node is on an Ethernet circuit, the target will 
attempt to perform an upline dump to the node that originally 
loaded it downline. If that node is not available, the target 
node proceeds as follows: 

1 The target node sends a memory dump request to the 
Ethernet dump assistance multicast address AB-00-00- 
01-00-00 (described in Section 3.3.3.4). This message is a 
request for any node on the Ethernet to receive an upline 
memory dump. 

2 The nodes on the Ethernet whose circuits are enabled to 
perform service functions check their own databases to 
determine if they can accept an upline dump. If so, they 
respond to the target node. The target choses the node 
responding first to continue the dumping sequence. The 
target does not send a message to any other node. The 
loading sequence continues normally from there. Note, 
however, that you may have to look for event 0.3 in the 
event logs for all nodes on the Ethernet to determine which 
node received the dump. See the NCP section of the 
VAX/VMS Utilities Reference Volume for a summary of all 
NCP events. 
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Figure 4-7 Upline Dumping of RSX-11S Memory 
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4.2.2 Upline Dump Requirements 

Prior to attempting an upline dump operation, you must 
ensure that the nodes, lines, and circuits meet the following 
requirements: 

• The slave node must be directly connected to the executor 
node by a physical line. The executor node provides the 
line- and circuit-level access. 

• The slave node must be capable of requesting the upline 
dump when it detects a system failure. If the dumping 
program does not exist on the slave, upline dumping cannot 
occur. 
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• The circuit involved in the dump operation must be enabled 
to perform service functions. It must also be in the ON 
state. For example, the following command readies circuit 
DMC-0 for upline dumping node BANGOR in the network 
example: 

NCP>SET CIRCUIT DMC-0 SERVICE ENABLED STATE ON 

• If the slave does not supply the DUMP COUNT value, the 
executor must have this value in its volatile database. 

• The executor must have a DUMP FILE entry in the volatile 
database. If the file-id specifies a remote node, the executor 
transfers the data using remote file access routines. 

• Upline dumping cannot occur unless you define a service 
timer for the line. This timer sets the timeout constant for 
retransmission, enabling MOP to handle error recovery. 

For example, to set the retransmission frequency to 5000 
milliseconds for line DMC-0, issue the command 

NCP>SET LINE DMC-2 SERVICE TIMER 5000 


4.3 Loading RSX-1 IS Tasks Downline 

Downline task loading extends nonresident initial task load, 
checkpointing, and overlay support to a DECnet RSX-1 IS 
node. You can load an RSX-1 IS task downline by using 
the Satellite Loader (SLD) on the DECnet-llS node and the 
host loader (HLD) on the DECnet-VAX node. SLD uses the 
intertask communication facilities of RSX DECnet-llS to 
communicate with HLD. Figure 4-8 illustrates one instance of 
this relationship. 

By entering RUN TLK at the operator's console of the satellite 
system, SLD requests HLD to load the task downline from a 
DECnet-VAX node on which the file is located. Any request 
from the satellite or host node could also initiate this operation 
by means of SLD and HLD. 
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Figure 4-8 Downline Task Loading 
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Setting Up the Satellite System 

You build the SLD task during the RSX-11S NETGEN pro¬ 
cedure. (Refer to the DECnet-RSX Network Generation and 
Installation Guide.) To allow downline task loading, issue the 
appropriate commands to the RSX-11S system image. Use 
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VMR to install and fix SLD into the RSX-11S system, as shown 
below. 

>VMR 

ENTER FILENAME: RSX1IS 
VMR>INS SLD 
VMR>FIX LDR... 

This sequence of commands establishes SLD as the loading task 
(LDR...) for the executive. 

Note: The information in this section is specific to DECnet-RSX 
and is therefore subject to inaccuracies. Refer to the related 
DECnet-RSX documentation. 

If the RSX-11S system is to be loaded downline, any tasks to be 
downline loaded to or checkpointed from the RSX-11S system 
must be installed, but not fixed, using VMR. For example: 

>VMR 

ENTER FILENAME: RSX1IS 
VMR>INS TLK 

In this example, entering RUN TLK on a terminal of the RSX- 
11S remote system initiates the downline task load of the file 
TLK.TSK. 

If the RSX-11S system will not be loaded downline, you must 
specify the node to which SLD will connect, using the VNP 
command SET EXECUTOR HOST (see the DECnet-RSX System 
Manager's Guide). For example, you could use the command 
below, where 11 is the number of the node BOSTON on which 
HLD resides: 

>VNP RSX11S 

VNP>SET EXECUTOR HOST 11 
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4.3.2 


Host Loader Mapping Table 

The Host Loader has a mapping table that is a special user- 
defined file (HLD.DAT) that resides in the SYS$SYSTEM 
directory. The format of the mapping table is as follows: 

HLDTB$ 

HTASK$ TLK,<TRNT0::SYS$DISK:[LOW]TLK>.UNM 
HTASK$ TLK,<SYS$DISK:[LOW.EXT]TLK>,MAP 
HNODE$ BANGOR 

HTASK$ NCP,<SYS$DISK:[LOW]NCP11S>,LUN 
HTASKS ...LOA,<SYS$DISK:[TEST]L0A> 

HNODE$ NYC 

HTASKS ...MCR,<LB:[RSX1IS.UNMAPPED]BASMCR> 

.END 

The keywords for this table are defined below. 

HLDTB$ Defines the file as the HLD mapping table. 

HTASK$ Defines a task entry. The arguments for HTASK$ are 

taskname, <file-spec> ,[opt-arg] 

taskname Is the installed task name used to run 
the task on the RSX-1 IS system. 

file-spec Is the task file specification on the host 
node. You must use angle brackets 
(<> ) to enclose the file specification. 

opt-arg Are optional arguments—MAP^NM^UN 

HNODE$ Defines the exclusive target node upon which the 
following HTASK$ can execute. 

This table is almost identical in structure to a MACRO-11 
source module used by DECnet-RSX to define its downline 
task loading tables. Note, however, that HLD.DAT is accessed 
directly as a text file and is neither assembled nor task built. 
The organization of the mapping table and special features is 
described below. 

• A task entry contains the name of the installed task, a file 
specification, and an optional control argument. The file 
specification in the HTASK$ macro can omit the file type 
that defaults to TSK. A node entry contains only the node 
name. 

• Any task entries that precede the first node entry are called 
general-purpose tasks. You can load a general-purpose task 
into any RSX--11S node in the network. Task entries that 
follow a node entry can only be sent to that particular node. 
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4.3.3 


• The same task name can appear more than once in the 
general-purpose task list. This allows both mapped and 
unmapped RSX-11S systems to share installed task names. 
The control argument for a general-purpose task is either 
MAP or UNM. The default is MAP. 

• Tasks to be loaded downline must be installed in the 
RSX-11S system, which initializes the task's logical unit 
number (LUN) assignments. LUN-fixing is an SLD feature 
that reinitializes the LUNs after the task has been loaded 
downline. This feature allows a single task to be loaded into 
multiple RSX-11S systems that may have different system- 
wide device assignments. SLD permits you to place a task 
in a general-purpose task list. You can downline load either 
a general-purpose task or a task after a node entry. 

• If you place a task in a general-purpose task list, you can 
add new nodes to the network and can downline load 
general-purpose tasks to those nodes without changing the 
mapping table. Nodes that are to receive only general- 
purpose tasks need not be mentioned in HLD.DAT. Note, 
however, that general-purpose tasks cannot be check- 
pointed. 


HLD Operation and Error Reporting 

When SLD attempts to connect to HLD, NETACP on the 
DECnet-VAX node uses the default inbound access control 
information specified for the HLD object by the system manager 
(see Section 3.13). You must make sure that the files associated 
with the tasks to be loaded or checkpointed are accessible from 
the resulting process created by this connection. 

When the load operation completes, whether successfully or 
unsuccessfully, the log file SYS$LOGIN:NETSERVER.LOG 
(described in Section 2.6.2) contains information describing the 
operation, the node, and the task. This information may consist 
of an error returned from RMS or certain HLD-specific messages 
that indicate either errors in HLD.DAT or inconsistencies in the 
file to be loaded. Messages associated with these inconsistencies 
are listed below. 
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4.3.3.1 HLD Error Messages 

The following is a list of HLD error messages. 

Format error in HLD.DAT 

The format of the HLD mapping table is incorrect. For example, 
this error could occur if HNODE$ was expected but not found 
in the table. Re-create the table with the appropriate format. 

Syntax error in HLD.DAT 

The syntax of an element in the HLD mapping table is incorrect. 
For example, you do not have angle brackets enclosing the file 
specification. Re-create the table. 

Task name not found 

The task to be loaded downline is not specified in the HLD 
mapping table. Re-create the table such that it contains this 
task name. 

No header in task file 

The file was built with the /-HD switch. Hence it is not a valid 
RSX-11S task image. Rebuild the task. 

Mapped task not on 4K boundary 

The file was not built with the /MM switch. This error is for 
mapped RSX-11S systems only. Rebuild the task. 

Unmapped partition mismatch 

The TKB address does not correspond with the starting address 
of the partition in the RSX-11S system. This error is for 
unmapped RSX-11S systems only. Rebuild the task with a 
PAR= statement that specifies the correct starting address. 

File too big for partition 

The initial load size of the file is larger than the partition size in 
the RSX-11S system. Either make the partition larger or rebuild 
the file to use a smaller partition size. 
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Partition too big for checkpoint space 

The partition size in the RSX-11S system is larger than the 
checkpoint space inside the file. Typically, this indicates that 
the partition size in your PAR= statement is smaller than the 
actual size of the partition in the RSX-11S system. Although 
the load size of a task may be much smaller than its partition, 
the entire partition is transferred during checkpoint operations. 
Rebuild the task with the exact partition size from the RSX-11S 
system. 


4.3.4 Checkpointing RSX—11S Tasks 

Checkpointing allows the execution of a task to be interrupted 
when a higher priority task installed in the same partition be¬ 
comes active. The software writes the interrupted task from 
RSX-11S memory to a checkpoint file on the host (Checkpoint 
Write) and then it loads the higher priority task into the parti¬ 
tion and activates it. When the priority task exits, the software 
restores the interrupted task into main memory (Checkpoint 
Read), where it continues executing. 

Note that checkpointing implies that a job is already running 
in the partition. Checkpoint space must be allocated inside the 
task being loaded downline (through the /AL switch during 
RSX-11S task build). 


4.3.5 Overlaying RSX-11S Tasks 

Overlaying allows the execution of segments of a task in order 
to reduce the memory or address space requirements for that 
task to run on an RSX-1 IS system. SLD and HLD handle the 
reading of overlay segments by satellite systems. 
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4.4 Connection to Remote Console 

DECnet-VAX allows you to set up a logical connection between 
your VAX/VMS node and the console interface on certain unat¬ 
tended nodes, in effect permitting your terminal to act as the 
console for the remote system. For example, your terminal can 
act as the console for the DIGITAL Ethernet Communications 
Server (DECSA) hardware and its resident software, such as 
the Router Server. The console carrier requester on the host 
connects to the console carrier server on the server. 

You can set up the logical connection to the console using the 
remote console facility (RCF). Both your host node and the 
target node (that is, the server node) must be on the same 
Ethernet. You can use the RCF to force a crash if the server 
node should become unresponsive. (To determine how to force 
a crash, see the appropriate documentation for the particular 
server product.) RCF also permits debugging under special 
circumstances. 

To use the RCF, you must be sure the console carrier server im¬ 
age and its loader file are present in the system directory on the 
host node. (The file name of the console carrier server image 
is PLUTOCC.SYS and that of the loader is PLUTOWL.SYS.) 

To invoke RCF, specify either the CONNECT NODE or CON¬ 
NECT VIA command. VAX/VMS then uses the loader file to 
downline load the console carrier server image into the Ethernet 
Communications Server hardware unit. 

Use the CONNECT NODE command if the name of the tar¬ 
get node is known. If the target node's service password and 
service circuit are defined in the host node's volatile database, 
you can use these default values. If the Ethernet hardware ad¬ 
dress of the server node is not defined in the volatile database, 
you must specify the PHYSICAL ADDRESS parameter in 
the CONNECT NODE command. Should you specify the 
Ethernet physical address of the target node, DECnet-VAX 
attempts to use it to load the image file. If you do not supply 
an Ethernet address, DECnet-VAX derives an Ethernet physical 
address from the target node number, first attempting to use 
this address, and then attempting to use the Ethernet hardware 
address. 
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To define default information for the target node in the volatile 
database, use the NCP command SET NODE to specify the 
SERVICE PASSWORD, SERVICE CIRCUIT, and HARDWARE 
ADDRESS parameters for the target node. You can override the 
target node parameter values currently defined in the volatile 
database by specifying new values in the CONNECT command. 

For example, to connect your VAX/VMS terminal to the console 
interface on server node RTRDEV, whose Ethernet physical 
address on circuit UNA-0 is AA-00-04-00-38-00, issue the 
command 

NCP> CONNECT NODE RTRDEV SERVICE PASSWORD FEFEFEFEFEFEFEFE - 
SERVICE CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-38-00 

Use the CONNECT VIA command if the node name of the 
target node is not known. In this command, you must specify 
the service circuit over which the logical connection is to be 
made and the Ethernet physical address of the target node. 

If you have not defined the hardware address of the server node 
in the volatile database and have not specified the Ethernet 
physical address of the node in the CONNECT command, 
DECnet-VAX displays an error message on your terminal as 
follows: 

Hardware address required 


The above message indicates that you must specify an Ethernet 
address for the target node in your CONNECT command, since 
no hardware address is available in the volatile database. 

In addition to the messages DECnet-VAX NCP or MOM may 
issue during downline loading of the console carrier server 
code, other messages described below may be issued when you 
attempt to connect to a remote console: 

Console in use 


The remote console has already been reserved for another 
purpose. Try to make the connection later. 

Console connected (press CTRL/D when finished) 
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The RCF is now ready for use. CTRL/B is used to pass a 
break character to the remote console. CTRL/D terminates the 
console session and causes the NCP prompt to be displayed. 

Target does not respond 


The remote console is supposed to respond quickly to inputs 
but is not doing so, or no connection can be made. 
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Configuration of a Network 


This chapter explains how to set up your VAX/VMS system 
for use in a DECnet-VAX network and provides sample 
configuration examples for various types of networks. 


5.1 Prerequisites for Establishing a Network 

Prior to configuring your DECnet-VAX node, you need to 
satisfy certain prerequisites for DECnet-VAX operation, such 
as setting up user accounts and directories, defining user 
privileges, and installing the key to your DECnet-VAX license. 
(Note that a DECnet-VAX license is required only if you are 
planning to run DECnet in a multinode environment.) 

If you are configuring VAX PSI, you must install it and define 
the privileges required for VAX PSI operation. If you are 
configuring VAX PSI in multihost mode (instead of native 
mode), you must install the VAX PSI multihost software on the 
VAX/VMS connector node that will serve as an X.25 gateway, 
and the VAX PSI Access software on each host node that will 
use the connector node. 


5.1.1 User Accounts and Directories 

In addition to creating normal user accounts in the user 
authorization file (UAF), you should also create a default 
DECnet account that can be used for activating network objects 
on the local node. DECnet-VAX uses the access privileges of 
this account when access control information has not been 
explicitly supplied by the network user. Section 3.13 discusses 
access control and the use of default accounts. Refer to the 
Guide to VAX/VMS System Management and Daily Operations for 
a description of how to create and use directories. 

The following example illustrates commands to establish a 
default DECnet account. If you use NETCONFIG.COM to 
configure your node and request a default DECnet account, 
the account will be created for you automatically (see 
Section 5.2.1.2). 
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$ SET DEFAULT SYSlSYSTEM 
$ RUN AUTHORIZE 

UAF>ADD NETN0NPRIV/PASSW0RD=N0NPRIV/DEVICE=DISK$USER1:- 
_ /DIRECTORY=[NETUSER]/UIC=[200,200]/PRIVILEGE=(TMPMBX,NETMBX)- 
_ /FLAGS=(CAPTIVE)/NOBATCH/NOINTERACTIVE/LGICMD=NL: 

UAF>EXIT 

$ CREATE/DIRECTORY DISK$USER1:[NETUSER]/OWNER_UIC=[200,200] 

Note that you must substitute your own device name in place 
of DISK$USER1 when you set up the default DECnet account. 

If you are configuring VAX PSI, ensure that you have the 
necessary PSI accounts, and the required directories associated 
with these PSI accounts, which will be used for incoming calls 
to your local DTE. You should also specify account information 
to activate objects at the local DTE for use by VAX PSI. 


5.1.2 Required Privileges 

To perform any kind of network activity, a process must have 
the privileges required to access the network processes involved 
in the activity requested. As system manager, you define a 
user's privileges in the UAF. The privileges listed in Table 5-1 
are at times required by the Network Management Listener 
(NML) and by those users of DECnet-VAX who are running 
NCP. The privileges listed in Table 5-2 are those required at 
times by both network users and system managers for VAX PSI 
operations. 


Table 5-1 Required DECnet-VAX Privileges 


Privilege Description 

ACNT Allows you to create subprocesses or detached 

processes in which accounting is disabled. ACNT is 
required to start the network. 

BYPASS Allows you to view passwords that would not 

otherwise be displayed by the NCP commands 
SHOW or LIST. 

CMKRNL Allows a process to change its access mode to 

kernel, execute a specified routine, and then return 
to its original access mode. Specifically, you need 
CMKRNL to start the network. 
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Table 5-1 (Cont.) Required DECnet-VAX Privileges 


Privilege 

Description 

DETACH 

Allows you to create detached processes by 
executing the $CREPRC system service. DETACH is 
required to bring up the network. 

NETMBX 

Allows you to assign a channel to the NET device. 
This privilege is required to create a logical link or to 
perform any ACP control QIO functions. NETMBX 
is the minimum requirement for all accounts running 
network programs. 

OPER 

Allows you to perform certain operator functions 
such as modifying the configuration database. 

(Refer to the Guide to VAX/VMS System 
Management and Daily Operations for a detailed 
explanation of the functions available under this 
privilege.) NML requires this privilege to modify any 
network parameters in the volatile database. 

TMPMBX 

Allows you to create temporary mailboxes. If you 
have this privilege, you can use the $CREMBX and 
$ASSIGN system services to create a temporary 
mailbox and assign an I/O channel for task-to-task 
communication. Unlike a permanent mailbox, which 
must be explicitly deleted, a temporary mailbox is 
automatically deleted when no more channels are 
assigned to it. TMPMBX is required for the default 
accounts and to run both NML and NCP. 

SYSNAM 

Allows you to declare a name or object number in 
a user task (see Chapter 8 for information on user 
tasks). 

SYSPRV 

Allows you to access the permanent database. 
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Table 5-2 Required VAX PSI Privileges 


Privilege 

Description 

DIAGNOSE 

Allows a system manager to use diagnostic 
functions. You can use it to run online diagnostic 
programs. DIAGNOSE is required if you want to 
perform line loop tests. 

NETMBX 

Allows a network user to assign a channel to the 
NET device. This channel is required to set up 
virtual circuits or to perform any ACP control QIO 
functions. NETMBX is required for all processes 
running network programs. 

OPER 

Allows a system manager to use the NCP 
commands. A detailed explanation of the NCP 
functions available under this privilege is given in the 
NCP section of the VAX/VMS Utilities Reference 
Volume. 

TMPMBX 

Allows a network user to create temporary 
mailboxes, that is, use the $ASSIGN system 
service to create a temporary mailbox and assign 
an I/O channel for DTE-to-DTE communication. 
Unlike a permanent mailbox, which must be 
deleted explicitly, a temporary mailbox is deleted 
automatically when no more channels are assigned 
to it. 

SYSPRV 

Allows a system manager to create and display 
objects and to perform tracing. 


Refer to Section 3.13 for a further discussion of network user 
privileges and their function in relation to overall network 
security. 
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5.2 Configuration Procedures 

Before installing DECnet-VAX on your system, there are certain 
tasks that you, as system manager, must complete to prepare 
for a networking environment. 

You must configure your DECnet-VAX permanent 
database. You can use the interactive procedure 
NETCONFIG.COM provided by Phase IV DECnet-VAX 
to do this. NETCONFIG.COM will prompt you for all the 
information needed to configure the permanent database and 
set up an optional default DECnet account on your system. If 
you choose not to use NETCONFIG.COM, you must use NCP 
commands to build the permanent database. Alternatively, 
you can use NCP commands to tailor the permanent database 
created by NETCONFIG.COM to your own needs. Also, you 
can use the NCP command COPY KNOWN NODES to build 
or update the remote node entries in your node database. 

You may have to perform additional configuration tasks 
depending upon your specific network requirements. If you 
plan to run DECnet-VAX over a Cl, you must install the 
DECnet driver CNDRIVER. Similarly, if you will be using some 
of your terminal lines as DECnet-VAX lines, you must install 
the asynchronous DDCMP driver NODRIVER. Sections 5.2.2.1 
and 5.2.2.2 describe these tasks in detail. 

Refer to the MicroVMS User's Manual if you will be configuring 
one or more MicroVMS systems as part of the network. 

If VAX PSI is to be run, the system manager is responsible 
for configuring VAX PSI for the local DTEs. This involves 
supplying information about various VAX PSI components, 
such as circuits, lines, modules, and objects. The information 
is contained in the DECnet-VAX configuration database for 
the local node (if both DECnet-VAX and PSI are configured) 
and in the PSI configuration database for the local DTEs. You 
use NCP commands to supply information to the configuration 
database. 
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5.2.1 


Using NETCONFIG.COM 

NETCONFIG.COM performs the following steps: 

1 Prompts you for the name and address of your node and 
asks whether or not you want a default DECnet account and 
whether you want to operate as a router or an end node. 

2 Determines which DECnet devices you have on your 
system. 

3 Creates and displays the NCP and DCL commands required 
to configure your DECnet-VAX node. 

4 Executes the commands displayed, if they are accepted, 
setting the appropriate parameters in the permanent 
configuration database at your node. This procedure 
establishes all databases (executor, line, circuit, object, 
logging) except for the remote node database. 

Use of this optional procedure is recommended when you are 
bringing up a new system as a DECnet-VAX node or when 
you wish to completely revise the configuration database for a 
system that is already running DECnet-VAX. 

Specifically, if you are bringing up a new system, follow the 
steps below. 

1 Execute NETCONFIG.COM. 

2 Use NCP commands to modify or add parameters once the 
initial database is configured. To make changes in or add 
DECnet accounts, use the DCL command AUTHORIZE. 

3 Set up the remote node database using NCP DEFINE NODE 
commands. 

4 Execute STARTNET.COM to bring up your DECnet-VAX 
node (see Section 6.2). 

If you are running DECnet-VAX on a node and wish to 
completely revise all permanent configuration databases 
except the remote node database, you should execute 
NETCONFIG.COM. To make any further alterations in the 
databases and DECnet accounts, use NCP and the DCL 
command AUTHORIZE. 
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5.2.1.1 


If you are running DECnet-VAX and wish to preserve the 
existing permanent database, do not use NETCONFIG.COM. 
Use NCP commands to make any desired changes in the 
database. 


Executing NETCONFIG.COM 

You must have system privilege (SYSPRV) to execute 
NETCONFIG.COM. To invoke the command procedure, issue 
the command 

$ <DSYS$MANAGER: NETCONFIG.COM 

The only information you must supply to the procedure is the 
node name and node address of your system. The node name 
is a string of up to six alphanumeric characters, containing at 
least one alphabetic character. The node address is a numeric 
value in the form 

area-number.node-number 


The number to the left of the period designates the area in 
which the node is grouped (in the range from 1 to 63) and the 
number to the right of the period designates the node's unique 
address within the area (in the range from 1 to 1023). If the 
network is not divided into multiple areas, you do not have to 
provide the area number; the system will supply the default 
area number 1. 

The procedure also asks whether you want a default DECnet 
account to be established for you. If you indicate yes (or take 
the default YES by pressing the RETURN key), the procedure 
displays the DCL AUTHORIZE command that would create 
a default DECnet account with a null password and a UIC of 
[376,376]. (Note that you can change this UIC value or other 
account parameters by using the Authorize Utility once the 
node is configured.) 

NETCONFIG.COM then asks if you want the executor node to 
function as a router. If you type NO (or take the default NO 
by pressing the RETURN key) in response to this question, the 
executor node will be set up as a nonrouting node. 

NETCONFIG.COM automatically determines which DECnet 
devices exist on your system for use in building the line and 
circuit permanent databases. NETCONFIG.COM then uses the 
information you supply and the information it obtains about the 
system to create all the commands necessary to configure your 
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system as a DECnet-VAX node, and displays these commands 
for your approval (see example below). The commands define 
the permanent database parameters for the executor; all lines, 
circuits, and objects; and all logging monitor events. The 
commands do not define the database for remote nodes. 

Inspect the displayed commands. NETCONFIG.COM will ask 
if you want to configure using these commands. If you answer 
yes, the procedure establishes the permanent configuration 
database and default DECnet account (if you requested it). If 
you answer no, the procedure returns a message indicating no 
changes have been made. 

Once the permanent database is established, you have the 
option of using NCP commands to alter the parameters to 
correspond more closely to your configuration requirements. 

If you use NETCONFIG.COM to establish the configuration 
database for a system that will be using asynchronous lines 
(for example, a Micro VMS system with a terminal line), 
NETCONFIG.COM will not configure the asynchronous circuit 
and line parameters automatically. Instead, NETCONFIG.COM 
will issue a message indicating that no circuits or lines have 
been configured. You must set up the asynchronous lines 
separately (see Section 5.2.2.2). 

If you have purchased a DECnet-VAX license and have not yet 
installed the key for that license, do so now. 

After configuring your DECnet-VAX system, start up the 
network by issuing the command 

$ <DSYS$MANAGER: STARTNET 

To ensure that the installation is successful, you can use the 
User Environment Test Package (UETP) to test DECnet. The 
test procedure is described in the Guide to VAX/VMS Software 
Installation . 


5.2.1.2 NETCONFIG.COM Example 

The following example shows the interactive dialog that is 
displayed when you execute NETCONFIG.COM to configure 
node CHCAGO. 
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DECnet-VAX network configuration procedure 

This procedure will help you define the parameters needed to get 
DECnet running on this machine. You will be shown the changes before 
they are actually executed, in case you wish to perform them manually. 

What do you want your DECnet node name to be? CHCAGO 

What do you want your DECnet address to be? 2.37 

Do you want a default DECnet account? [YES] 

Do you want to operate as a router? [NO (nonrouting)] 

Here are the commands necessary to set up your system. 


RET 

RET 


$ RUN SYS$SYSTEM:NCP 

PURGE EXECUTOR ALL 
PURGE KNOWN LINES ALL 
PURGE KNOWN CIRCUITS ALL 
PURGE KNOWN LOGGING ALL 
PURGE KNOWN OBJECTS ALL 

PURGE MODULE CONFIGURATOR KNOWN CIRCUITS ALL 
$ DEFINE/USER SYSlOUTPUT NL: 

$ DEFINE/USER SYS$ERR0R NL: 

$ RUN SYS$SYSTEM:NCP 

PURGE NODE 2.37 ALL 
PURGE NODE CHCAGO ALL 
$ RUN SYS$SYSTEM:NCP 

DEFINE EXECUTOR ADDRESS 2.37 STATE ON 
DEFINE EXECUTOR NAME CHCAGO 
DEFINE EXECUTOR MAXIMUM ADDRESS 255 
DEFINE EXECUTOR ROUTING TYPE NONROUTING IV 
DEFINE EXECUTOR NONPRIVILEGED USER DECNET 
$ DEFINE/USER SYSUAF SYS$SYSTEM:SYSUAF.DAT 
$ RUN SYSISYSTEM:AUTHORIZE 

ADD DECNET /OWNER="DECNET DEFAULT" - 
/PASSWORDS" - 

/UIC=[376,376] /ACCOUNT=DECNET - 
/DEVICE=SYS$SYSDEVICE: /DIRECTORY=[DECNET] - 
/PRIVILEGE=(TMPMBX.NETMBX) 

/FLAGS=(CAPTIVE) /LGICMD=NL: - 
/NOBATCH /NOINTERACTIVE 

$ CREATE/DIRECTORY SYS$SYSDEVICE:[DECNET] /OWNER=[376,376] 
$ RUN SYSISYSTEM:NCP 

STATE ON 
STATE ON 
STATE ON COST 3 
STATE ON 
STATE ON COST 5 
STATE ON 
STATE ON 


DEFINE LINE CI-0 
DEFINE LINE UNA-0 
DEFINE CIRCUIT UNA-0 
DEFINE LINE DMC-0 
DEFINE CIRCUIT DMC-0 
DEFINE LINE DMC-1 
DEFINE CIRCUIT DMC-1 


COST 

DEFINE LOGGING MONITOR STATE ON 
DEFINE LOGGING MONITOR EVENTS 00-9 
DEFINE LOGGING MONITOR EVENTS 
DEFINE LOGGING MONITOR EVENTS 
DEFINE LOGGING MONITOR EVENTS 
DEFINE LOGGING MONITOR EVENTS 


2 0-1 

4 2-13,15-16,18-19 

5 0-18 
128.0-4 


Do you want to go ahead and do it? [YES]: NO 

No changes have been made. 
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5.2.2 Tailoring the Configuration Database 

If you do not choose to use NETCONFIG.COM to build 
the network configuration in the permanent database, you 
may instead configure the network using individual NCP 
commands. Examples of various configuration procedures are 
given in Section 5.3 . NCP can also be used to add or delete 
entries in an existing permanent database. 

Following are two examples of changes made to the network 
configuration that require corresponding modification of the 
permanent database. 

• Running DECnet over the CI. The driver CNDRIVER must be 
loaded on the system and all CI lines and circuits must be 
defined in the configuration database. 

• Running DECnet over terminal lines. The terminal driver 
NODRIVER must be loaded on the system, terminal lines 
must be converted to DDCMP lines, and all DDCMP lines 
and circuits must be defined in the configuration database. 

The procedures for handling these changes are described in 
detail in the following sections. 


5.2.2.1 Running DECnet Over the Cl 

To use the CI750 or CI780 as a DECnet device on your 
VAX/VMS system, you must first install CNDRIVER, the 
DECnet driver associated with the CI. To load CNDRIVER, add 
the following commands to the LOADNET.COM command 
procedure in the SYS$MANAGER directory. 

$ RUN SYSlSYSTEM:SYSGEN 
$ CONNECT CNAO/NOADAPTER 

You are now ready to run DECnet over the CI. The following 
example illustrates how to use NCP commands to define the CI 
line and one or more CI circuits in the permanent database. 

$ RUN SYSISYSTEM:NCP 
NCP>DEFINE LINE CI-0 STATE ON 
NCP>DEFINE CIRCUIT CI-0.0 TRIBUTARY 0 STATE ON 
NCP>DEFINE CIRCUIT CI-0.1 TRIBUTARY 1 STATE ON 


NCP> EXIT 

$ 
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5.2.2.2 Running DECnet Over Terminal Lines 

To use lines connected to terminal ports as DECnet 
communications lines, you must load the asynchronous 
DDCMP driver NODRIVER, set up the terminal lines to 
be converted to asynchronous DDCMP lines, and specify 
the appropriate lines and circuits in the NCP configuration 
database. The steps in converting terminal lines to 
asynchronous lines depend on the type of line you want to 
set up: 

• Static asynchronous DDCMP line: a line permanently 
configured as a DECnet line 

• Dynamic asynchronous DDCMP line: a line that is switched 
from terminal to DECnet use for the duration of a dialup 
call 

Procedures for installing and shutting down each of these types 
of lines are described below. 

Because dialup lines are more prone to noise problems than 
dedicated synchronous lines that do not use modems, it is 
recommended that the executor buffer size and segment buffer 
size be set to a value of 192 for any end node that is connected 
to its router by a dialup line. Use of a relatively small buffer 
size will reduce the effect of buffer retransmission on overall 
throughput. 


5.2.2.3 Installing Static Asynchronous Lines 

The following procedures illustrate the steps in setting up and 
shutting down static asynchronous lines on your system. 

Setting Up Static Asynchronous DDCMP Lines 

The steps necessary to set up lines connected to terminal ports 
on your system for use as static asynchronous DECnet lines are: 

1 Load the asynchronous DDCMP driver NODRIVER. 

To load this driver, add the following commands 
to the LOADNET.COM command procedure in the 
SYS$MANAGER directory or specify the commands after 
the system is booted. 

$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT NOAO/NOADAPTER 
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2 Choose the terminal lines on your system that you will use 
as DECnet lines. To convert a line to a static asynchronous 
DDCMP line with no modem control, add the following 
command to LOADNET.COM in your SYS$MANAGER 
directory as many times as required. 

$ SET TERMINAL/PROTOCOL=DDCMP device-name: 

For example, to convert the terminal lines connected to ports 
TTAO and TXB7 on your system into DECnet lines, add the 
following to the LOADNET.COM procedure. 

$ SET TERMINAL/PROTOCOL=DDCMP TTAO: 

$ SET TERMINAL/PROTOCOL=DDCMP TXB7: 

To convert a line enabling modem control (for example, 
the line connected to terminal port TXA1, which can be 
used as a dialup line), add the following command to 
LOADNET.COM: 

$ SET TERMINAL/PERMANENT/MODEM/NOHANGUP/NOAUTOBAUD - 
_$ /NOTYPEAHEAD/PROTOCOL=DDCMP TXA1: 

Note that the line speed cannot be changed while the 
terminal line is in use as a DECnet communications line. 

3 Define all terminal lines and circuits in the configuration 
database using NCP commands. The following example 
shows how to add the terminal circuits and lines to the 
permanent database. 

$ RUN SYS$SYSTEM:NCP 

NCP>DEFINE LINE TT-0-0 STATE ON RECEIVE BUFFERS 4 - 
LINE SPEED 9600 

NCP>DEFINE CIRCUIT TT-0-0 STATE ON 
NCP>DEFINE LINE TX-1-7 STATE ON RECEIVE BUFFERS 4 - 
LINE SPEED 1200 

NCP>DEFINE CIRCUIT TX-1-7 STATE ON 


NCP>EXIT 

$ 

The lines are then turned on to the network. 
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Reasons for Faiilure of Static Asynchronous Connections 

If static asynchronous DECnet lines are started but are left in 
the "ON - STARTING" state, check the following: 

• The line speeds must be set to the same value. 

• If you are using a dialup line, the modem characteristic 
must be set on the terminal before the line is switched to 
asynchronous DDCMP use. 

• If the network is divided into areas, the two nodes being 
connected must be in the same area. 

• Asynchronous DECnet requires that the parity on the 
asynchronous line be set to NONE and the terminal line be 
set up to use 8-bit characters. If you are using a non-VMS 
system, you must check that the terminal line is set to the 
correct parity. 

Shutting Down Static Asynchronous DDCMP Lines 

To shut down the DECnet lines and return them to terminal 
lines, first specify the following commands: 

$ RUN SYS$SYSTEM:NCP 
NCP>SET LINE TT-0-0 STATE OFF 
NCP>CLEAR LINE TT-0-0 ALL 
NCP>SET CIRCUIT TT-0-0 STATE OFF 
NCP>CLEAR CIRCUIT TT-0-0 ALL 

To switch the line for which modem control was not enabled 
back to a terminal line, use this command: 

$ SET TERMINAL/PROTOCOL=NONE TXA1: 

To switch the line for which modem control was enabled back 
to a terminal line, use this command: 

$ SET TERMINAL/PERMANENT/NOMODEM/HANGUP/AUTOBAUD - 
_$ TYPEAHEAD/PROTOC'OL=NONE TXA1: 
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5.2.2.4 Installing Dynamic Asynchronous Lines 

To make a temporary connection to another node over a 
telephone line, the terminal lines at each node must be switched 
to dynamic asynchronous DDCMP lines for the duration of 
the connection. The procedure for establishing a dynamic 
connection, reasons why the connection might fail, and the 
actions that shut down the lines are described below. 

Setting Up Dynamic Asynchronous DDCMP Lines 

The steps necessary to set up a dynamic connection, switching 
lines connected to terminal ports to dynamic asynchronous 
DECnet lines, are outlined below. This procedure illustrates 
commands used if a local Micro VMS system (MYNODE) is 
establishing a dynamic connection with a remote VAX/VMS 
system (BIGVAX). 

1 The system manager at each node must load the 

asynchronous DDCMP driver NODRIVER. To load this 
driver, add the following commands to the LOADNET.COM 
command procedure in the SYS$MANAGER directory or 
specify the commands after the system is booted. 

$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> CONNECT NOAO/NOADAPTER 


2 The system manager at each node must install the shareable 
image DYNSWITCH as follows: 

$ INSTALL:=SYS$SYSTEM:INSTALL 
$ INSTALL/COMMAND 

INSTALL> CREATE SYS$LIBRARY:DYNSWITCH/SHARE - 
_ /PROTECT/HEADER/OPEN 
INSTALL> EXIT 

Note that if the image DYNSWITCH is not installed on the 
system, dynamic switching of lines is implicitly disabled. 

3 The system manager at the remote node BIGVAX must 
enable the virtual terminal (for example, VTAO) with these 
commands: 

$ RUN SYS$SYSTEM:SYSGEN 

SYSGEN> CONNECT VTAO/NOADAPTER/DRIVER=TTDRIVER 

For further information on using virtual terminals, refer to 
the description of process preservation across hangups in the 
VAX/VMS I/O User's Reference Manual: Part 1. 
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4 Log in to the local system and issue the command below 
to establish the system as a terminal emulator. (TTA1 
identifies the terminal port on the local system through 
which the dynamic connection will be made). 

$ SET HOST/DTE TTA1: 

5 Dial in to the remote system and log in to your account on 
the remote node BIGVAX. You can optionally include the 
/DIAL qualifier in the SET HOST command specified above 
to cause automatic dialing of the modem to the remote 
node. 

6 Initiate dynamic switching by specifying the following 
command: 

$ SET TERMINALy'PROTOCOL=DDCMP/SWITCH=DECNET 

Dynamic switching of the terminal lines to asynchronous 
DDCMP lines occurs automatically at both ends of the 
connection. 

7 DECnet is started at the local node and you receive the 
following message: 

7. REM - control returns to local-node-name: 

$ 

At the remote system prompt ($), you can begin to use the 
line for network operations. 

8 If your local terminal emulator does not support automatic 
switching, then you must specify the /MANUAL qualifier 
in the SET TERMINAL command in step 6. The remote 
system will send you the following message: 

7. SET-I-SWINPRG The line you are currently logged 
over is becoming a DECnet line 

On the local system, you should exit the terminal emulator 
and switch your terminal line manually by specifying: 

$ SET TERMINAL/PROTOCOL=DDCMP TTA1: 

Note that the SET TERMINAL command is a VAX/VMS 
DCL command. If you are on a non-VAX/VMS node, you 
should specify the equivalent function for your system. 

You should enter NCP commands to turn on your line and 
circuit. DECnet is then started at the local node. 
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Reasons for Failure of Dynamic Asynchronous 

Connections 

If dynamic switching is being performed and the asynchronous 

DECnet connection is not made, first check that the following 

conditions exist: 

• DECnet must be started on both nodes. 

• The asynchronous DDCMP class driver (NODRIVER) must 
be loaded by means of SYS$SYSTEM:SYSGEN at each 
node. 

• The dynamic switch image (DYNSWITCH) must be installed 
by means of SYS$SYSTEM:INSTALL at each node. 

• Virtual terminals must be enabled on the remote node and, 
in particular, must be enabled for the terminal over which 
you are logged in. 

If the dynamic asynchronous lines are started but are left in the 

"ON - STARTING" state, check the following: 

• If the network is divided into areas, the two nodes being 
connected must be in the same area. 

• The routing initialization passwords on each node must be 
set correctly. 

• The INBOUND parameter in the remote node entry must be 
set correctly in the node database at the local node. 

• Asynchronous DECnet requires that the parity on the 
asynchronous line be set to NONE and the terminal line be 
set up to use 8-bit characters. If you are using a non-VMS 
system, you must check that the terminal line is set to the 
correct parity. 

Shutting Down Dynamic Asynchronous Lines 



You have two options for ending a dynamic connection: 

• Break the telephone connection. 

• Specify either of these NCP commands: 


NCP>SET LINE TT-0-0 STATE OFF 
NCP>SET CIRCUIT TT-0-0 STATE OFF 
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Note that if you specified the /NOHANGUP qualifier in the 
SET TERMINAL command with which you initiated dynamic 
switching, the modem carrier signal will not be dropped when 
you shut down the DECnet line or circuit. The carrier signal 
will be broken when you hang up the telephone. 


5.3 Network Configuration Examples 



This section illustrates how you can use NCP commands to 
build your network configuration in the permanent database. 
Included are examples of the NCP commands you would use to 
obtain the following network configurations: 

• Synchronous DDCMP point-to-point configuration 

• DDCMP multipoint configuration 

• Static asynchronous DDCMP point-to-point configuration 

• Dynamic asynchronous DDCMP point-to-point 
configuration 

• Ethernet configuration 

• X.25 DLM configuration 

• X.25 native-mode configuration 

• X.25 multihost mode configuration 

Note that the configuration examples in this section assume 
single-area networks using the default area 1. For an example 
of the NCP commands used to configure a multiple-area 
network, see Section A.3. 

Combine the appropriate NCP commands in a command file 
that reflects your network configuration; then edit and run this 
procedure as many times as necessary to properly build the 
permanent database corresponding to your configuration and 
needs. Once you have configured the permanent database, 
invoke SYS$MANAGER:STARTNET.COM to load these 
parameters into the volatile database and bring up the network. 
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5.3.1 Synchronous DDCMP Point-to-Point Network 

Example 

The example below builds a database for a network 
configuration of four nodes, connected together by a DMC11, 
DMP11 or DMF32 line and circuit. 


Figure 5-1 A Synchronous DDCMP Point-to-Point Network 
Configuration 


CHCAGO 



NEWARK 

ATLNTA 

TAMPA 


ZK-1852-84 


Use the following NCP commands to configure the DDCMP 
point-to-point network. Note that node NEWARK is a 
nonrouting RSX-11S system to which node CHCAGO will 
perform a downline load. 


Define executor-specific parameters for local node CHCAGO. 
The TYPE parameter for the executor node defaults to 
ROUTING IV. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 
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Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME CHCAGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define parameters for remote node NEWARK (a nonrouting 
RSX-11S system). CHCAGO will be the load host for NEWARK. 

DEFINE NODE 2 NAME NEWARK - 

HOST NODE CHCAGO - 
LOAD FILE NODUS. SYS - 
NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV - 
SERVICE CIRCUIT DMC-0 - 
SERVICE PASSWORD FE - 
SECONDARY LOADER SECDMC.SYS - 
TERTIARY LOADER TERDMC.SYS 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 

DEFINE NODE 3 NAME ATLNTA 

DEFINE NODE 4 NAME TAMPA 


Define parameters for line/circuit DMC-0 to node NEWARK. 

Because this node will be loaded downline, the service 
parameters must be set up. 


DEFINE LINE DMC-0 


DEFINE CIRCUIT DMC-0 


PROTOCOL DDCMP POINT - 
SERVICE TIMER 4000 - 

STATE ON 

SERVICE ENABLED - 
STATE ON 


Define parameters for line/circuit DMF-0 to node ATLNTA. 

(Give this line more receive buffers because it has a faster 
connection.) 

DEFINE LINE DMF-0 PROTOCOL DDCMP POINT - 

RECEIVE BUFFERS 8 - 

STATE ON 

DEFINE CIRCUIT DMF-0 STATE ON 
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Define parameters for line/circuit DMP-0 to node TAMPA. 

DEFINE LINE DMP-0 PROTOCOL DDCMP POINT - 

STATE ON 

DEFINE CIRCUIT DMP-0 STATE ON 

The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 

Define transmitter-related logging parameters. 

DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 

DEFINE LOGGING MONITOR STATE ON 


5.3.2 DDCMP Multipoint Network Example 

This example builds a database for a network configuration of 
five nodes, connected together by a combination of DMC, DMF, 
and DMP lines and circuits. 


Figure 5-2 A DDCMP Multipoint Network Configuration 


CHCAGO 



PHILA 

ATLNTA 


TAMPA MIAMI 
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Use the following NCP commands to configure the DDCMP 
multipoint network: 


Define executor-specific parameters for local node CHCAGO. 
The TYPE parameter for the executor node defaults to 
ROUTING IV. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 

Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 


DEFINE EXECUTOR 


NAME CHCAGO - 
NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 


DEFINE NODE 2 
DEFINE NODE 3 
DEFINE NODE 4 
DEFINE NODE 5 


NAME PHILA 
NAME ATLNTA 
NAME TAMPA 
NAME MIAMI 


Define parameters for line/circuit DMC-0 to node PHILA. 

DEFINE LINE DMC-0 PROTOCOL DDCMP POINT - 

STATE ON - 

DEFINE CIRCUIT DMC-0 STATE ON 


Define parameters for line/circuit DMF-0 to node ATLNTA. 


DEFINE LINE DMF-0 

DEFINE CIRCUIT DMF-0 


PROTOCOL DDCMP POINT 
STATE ON 

STATE ON 
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Define parameters for line DMP-0 and circuits to nodes TAMPA 
and MIAMI. 


TAMPA is connected as tributary 3, DMP-O.0 
MIAMI is connected as tributary 4. DMP-O.1 

The DMP line runs at 56,000 bits per second. The proper 
setting for the retransmit timer is 


retransmit timer = 


20,000 * buffer_size 


bps 


Thus, with a buffer size of 576, the retransmit timer should 
be 210 milliseconds. 


The dead timer is set to 30 seconds to avoid excessive delays 
when polling dead tributaries. The timer is set when a node 
goes down. 


DEFINE LINE DMP-O 

DEFINE CIRCUIT DMP-O.0 

DEFINE CIRCUIT DMP-O.1 


PROTOCOL DDCMP CONTROL 
DEAD TIMER 30000 - 

RECEIVE BUFFERS 6 - 

RETRANSMIT TIMER 210 - 
STATE ON 

COST 4 - 

STATE ON - 
TRIBUTARY 3 

COST 4 - 

STATE ON - 
TRIBUTARY 4 


The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 

Define transmitter-related logging parameters. 

DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 

DEFINE LOGGING MONITOR STATE ON 
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5.3.3 Static Asynchronous DDCMP Network Example 

The example below builds a database for a network 
configuration of four nodes, connected by a DMR11 line and 
two terminal lines converted to static asynchronous DECnet 
lines. 


Figure 5-3 A Static Asynchronous DDCMP Network 
Configuration 


CHCAGO 



ST PAUL 

YELLOW 

BLUE 


ZK-1854-84 


Use the following NCP commands to configure the DDCMP 
point-to-point network that includes static asynchronous 
lines. To establish the static asynchronous connections, nodes 
YELLOW and BLUE must also specify in their configuration 
databases the circuits and lines connecting them to node 


CHCAGO. 


Define executor-specific parameters for local node 

CHCAGO. The TYPE parameter for the executor node defaults to 

ROUTING IV. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 
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Define common node parameters for the local node. Be 
sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME CHCAGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. Note that no default 
outbound access control information is specified. 
This assumes that the default access control 
information will be supplied by each remote node 
when it receives an inbound connect request. 


DEFINE NODE 2 
DEFINE NODE 3 
DEFINE NODE 4 


Define parameters for 
STPAUL. 


DEFINE LINE DMR-0 


DEFINE CIRCUIT DMR-0 


NAME STPAUL 
NAME YELLOW 
NAME BLUE 

line/circuit DMR-0 to node 

PROTOCOL DDCMP POINT 
STATE ON 

STATE ON 


Define parameters for line/circuit TT-0-0 to node 
YELLOW. 


DEFINE LINE TT-0-0 RECEIVE BUFFERS 4 

STATE ON 
LINE SPEED 9600 

DEFINE CIRCUIT TT-0-0 STATE ON 


Define parameters for line/circuit TX-1-7 to node 
BLUE. 


DEFINE LINE TX-1-7 RECEIVER BUFFERS 4 - 

STATE ON 
LINE SPEED 1200 

DEFINE CIRCUIT TX-1-7 STATE ON 


The object database does not need to be defined 
because it defaults to the standard list of objects 
known to VAX/VMS. 


Define transmitter-related logging parameters. 
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DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 
DEFINE LOGGING MONITOR STATE ON 


5.3.4 Dynamic Asynchronous DDCMP Network Example 

The example below indicates the NCP commands to configure 
two nodes, connected by a terminal line converted to a dynamic 
asynchronous DECnet line. 

Figure 5-4 A Dynamic Asynchronous DDCMP Network 
Configuration 


BIGVAX 


MYNODE 



5.3.4.1 Node BIGVAX Database 

Use the following NCP commands to configure the dynamic 
asynchronous DDCMP connection from node BIGVAX to node 
MYNODE. This example assumes BIGVAX is a router. 


Define executor-specific parameters for local node 
BIGVAX. 


DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 
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Define common node parameters for the local node. Be 
sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME BIGVAX - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 

Define the remote node. You must use the INBOUND 
parameter to check whether dialup node MYNODE will 
operate as an endnode or as a router. As an added 
security feature for a node using a dynamic asynchronous 
communications line, you must also specify a receive 
password for node MYNODE. This will be compared with 
the transmit password supplied by MYNODE when it 
issues the connect request. 

DEFINE NODE 2 NAME MYNODE - 

INBOUND ENDNODE - 
RECEIVE PASSWORD 10101010 

You do not need to define parameters for a 
line/circuit to node MYNODE. These parameters are 
provided automatically by the system when the dynamic 
connection is initiated. 


The object database does not need to be defined 
because it defaults to the standard list of objects 
known to VAX/VMS. 


Define transmitter-related logging parameters. 
DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 
DEFINE LOGGING MONITOR STATE ON 
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5.3.4.2 Node MYNODE Database 

Use the following NCP commands to configure the dynamic 
asynchronous DDCMP connection from node MYNODE to 
node BIGVAX. This example assumes that MYNODE is an end 
node and that the dynamic line is a slow (1200 baud) modem 
line. 


Define executor-specific parameters for local node 
MYNODE. 

DEFINE EXECUTOR ADDRESS 2 - 

BUFFER SIZE 192 - 

SEGMENT BUFFER SIZE 192 - 
STATE ON 

Define common node parameters for the local node. 

Be sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME MYNODE - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remote node. You must specify a transmit 
password which matches the receive password in the 
remote node database on node BIGVAX. 


DEFINE NODE 1 NAME BIGVAX - 

TRANSMIT PASSWORD 10101010 


You do not need to define parameters for a 
line/circuit to node BIGVAX. These parameters are 
provided automatically by the system when the dynamic 
connection is initiated. 


The object database does not need to be defined 
because it defaults to the standard list of objects 
known to VAX/VMS. 
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5.3.5 Ethernet Network Example 

This example builds a database for a network configuration of 
three nodes, connected by an Ethernet UNA line and circuit. 


Figure 5-5 An Ethernet Network Configuration 


UNA-0 



ROBIN THRUSH LARK 


ZK-1855-84 


Use the following NCP commands to configure the node 
ROBIN database. Repeat the procedure to configure the 
databases for nodes THRUSH and LARK. 


Define executor-specific parameters for local node ROBIN. 
Note that the TYPE parameter for the executor node defaults 
to a node-type that corresponds to the type of network 
license (router or end node) you have installed. 

DEFINE EXECUTOR ADDRESS 20 - 

BUFFER SIZE 576 - 

STATE ON 


Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME ROBIN - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 
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5.3.6 


5.3.6.1 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 

DEFINE NODE 21 NAME THRUSH 

DEFINE NODE 22 NAME LARK 


Define parameters for line/circuit UNA-O. 

DEFINE LINE UNA-0 STATE ON 

DEFINE CIRCUIT UNA-0 STATE ON 


The object database does not need to be defined because 
it defaults to the standard list of objects known to VAX/VMS. 


Define transmitter-related logging parameters. 
DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 
DEFINE LOGGING MONITOR STATE ON 


X.25 Data Link Mapping Example 

This example builds a database for a network configuration of 
three nodes, connected by a DMC11 line and circuit and an 
X.25 packet switching data network (PSDN). 


Node CHCAGO Database 

Use the following NCP commands to configure the node 
CHCAGO database. 


Set up the X.25 protocol module. 

DEFINE MODULE X25-PROTOCOL - 

NETWORK TELENET 

Define the line used to communicate with the X.25 network. 
DEFINE LINE DUP-0 STATE ON 
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Figure 5-6 An X.25 Data Link Mapping Network Configuration 


CHCAGO 


X25-OUT 

I 

DTE 311111222333 



X25-INC 


SDIEGO 



BUFFLO 


ZK-1856-84 


Define the local DTE for node CHCAGO. (The number 311 at 
the beginning of the DTE address signifies TELENET.) 


DEFINE MODULE X25-PR0T0C0L - 

DTE 311111222333 - 

CHANNELS 2018-1546 - 

LINE DUP-0 
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Define executor specific parameters for local node CHCAGO. 
The TYPE parameter for the executor node defaults to 
ROUTING IV. 

DEFINE EXECUTOR ADDRESS 1 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

STATE ON 

Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME CHCAGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


! Define the remaining nodes. Note that no default outbound 
! access control information is specified. This assumes that 

! the default access control information will be supplied by 

! each remote node when it receives an inbound connect request. 

DEFINE NODE 2 NAME BUFFLO 

DEFINE NODE 3 NAME SDIEGO 

j 

! Define parameters for line/circuit DMC-0 to node BUFFLO. 

! 


DEFINE LINE DMC-0 
DEFINE CIRCUIT DMC-0 


PROTOCOL DDCMP POINT 
STATE ON - 

STATE ON 


Define parameters for the outgoing DLM circuit X25-0UT to node 
SDIEGO (node SDIEGO is addressed as DTE 311444555666 to the 
X.25 network; subaddress 1 is defined on node SDIEGO to be a 
DECnet DLM subaddress). 


DEFINE CIRCUIT X25-0UT - 

NUMBER 3114445556661 - 
OWNER EXECUTOR - 
USAGE OUTGOING - 
STATE ON 
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The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 

Define transmitter-related logging parameter. 

DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 

DEFINE LOGGING MONITOR STATE ON 


5.3.6.2 Node SDIEGO Database 

Use the following NCP commands to configure the node 
SDIEGO database. 


Set up the X.25 protocol module. 

DEFINE MODULE X25-PR0T0C0L - 

NETWORK TELENET 


Define the line used to communicate with the X.25 network. 


DEFINE LINE DUP-0 STATE ON 


Define the local DTE for node SDIEGO. 


DEFINE MODULE X25-PR0T0C0L - 

DTE 311444555666 - 

CHANNELS 2490-2452 - 

LINE DUP-0 

Define executor-specific parameters for local node SDIEGO. 
Note that the X.25 subaddress range is given as 1 to 5 so 
that this node can accept all X.25 calls with a subaddress 
from 1 to 5. Because CHCAGO is sending X.25 calls and does 
not intend to receive any, you need not specify the 
subaddress parameter for this DTE. The system manager must 
coordinate the subaddress values used to designate DECnet 
data link calls among the DECnet nodes. 

DEFINE EXECUTOR ADDRESS 3 - 

BUFFER SIZE 576 - 

MAXIMUM HOPS 6 - 

MAXIMUM VISITS 12 - 

SUBADDRESSES 1-5 - 

STATE ON 
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5.3.7 


Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME SDIEGO - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 
each remote node when it receives an inbound connect request. 

DEFINE NODE 1 NAME CHCAGO 

DEFINE NODE 2 NAME BUFFLO 

Define parameters for the incoming DLM circuit X25-INC (to 
node CHCAGO). 

DEFINE CIRCUIT X25-INC OWNER EXECUTOR - 

USAGE INCOMING - 
STATE ON 


The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 


Define transmitter-related logging parameters. 


DEFINE LOGGING MONITOR KNOWN EVENTS 


Define receiver-related logging parameters. 


DEFINE LOGGING MONITOR STATE ON 


X.25 Native Mode Network Example 

This example builds a database for a network configuration 
associating a local DTE with a packet switching data network 
(the United Kingdom PSDN called PSS) by a DUP line. The 
example builds server and object modules to handle incoming 
calls. 
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Figure 5-7 An X.25 Native-Mode Network Configuration 


DTE 234123456789 



ZK-1857-84 


Use the following NCP commands to configure the permanent 
database for the X.25 native-mode network. 


Set up the X.25 protocol module. 

DEFINE MODULE X25-PR0T0C0L - 

NETWORK PSS 


Define the line used to communicate with the X.25 network. 


DEFINE LINE DUP-0 STATE ON 


Define the local DTE. 

(The number 234 at the beginning of the DTE address identifies 
the PSDN.) 

DEFINE MODULE X25-PR0T0C0L - 

DTE 234123456789 - 
CHANNELS 2018-1546 - 
LINE DUP-0 
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5.3.8 


Define the destinations. 


DEFINE MODULE X25-SERVER - 

DESTINATION JOE - 
SUBADDRESS 1-10 - 
OBJECT OBJONE - 
PRIORITY 1 

DEFINE MODULE X25-SERVER - 

DESTINATION JIM - 
SUBADDRESS 11-15 - 
OBJECT OBJTWO - 
PRIORITY 2 

DEFINE MODULE X25-SERVER - 

DESTINATION DEFDEST - 
OBJECT DEFOBJ - 
PRIORITY 0 


Define the X.29 call handler. 


DEFINE MODULE X29-SERVER STATE ON 


Define the objects used for incoming calls. 
DEFINE OBJECT OBJONE - 

FILE OBJSTUP.COM - 
USER PSIUSER - 
PASSWORD PSIUSER 

DEFINE OBJECT OBJTWO - 

FILE OBJECTTWO.COM - 
USER JIM - 
PASSWORD JIM 

DEFINE OBJECT DEFOBJ - 

FILE LSTCHNCE.COM - 
USER NET - 
PASSWORD NET 


X.25 Multihost Mode Network Example 

The following example illustrates the NCP commands used 
to configure three VAX/VMS nodes connected by an Ethernet 
UNA line and circuit, with one node set up as an X.25 multihost 
connector node to the PSDN called PSS and the other two 
nodes set up as host nodes to use the connector node. 

In this example, node ROBIN, with VAX PSI and multihost 
PSI software installed, is configured as the connector node, and 
nodes THRUSH and LARK, each with VAX PSI Access software 
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installed, are configured as host nodes that can communicate 
with the X.25 network through ROBIN. 


Figure 5-8 An X.25 Multihost Mode Network Configuration 




ZK-1858-84 


You must complete the following tasks in order to configure 
this network: 

• Build the Ethernet network. 

• Build the appropriate databases on ROBIN to configure this 
node as the X.25 connector node. 

• Configure THRUSH and LARK as host nodes capable of 
accessing the X.25 network through the connector node 
ROBIN. 
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5.3.8.1 Building the Ethernet Network 

Use the following NCP commands to configure the node 
ROBIN database. Repeat the procedure to configure the 
databases for nodes THRUSH and LARK. 


Define executor-specific parameters for local node 
ROBIN. The TYPE parameter for the executor node defaults 
to ROUTING IV. 

DEFINE EXECUTOR ADDRESS 20 - 

BUFFER SIZE 576 - 

STATE ON 


Define common node parameters for the local node. Be sure 
to add the NETNONPRIV user to your system authorization 
file by using the Authorize Utility. 

DEFINE EXECUTOR NAME ROBIN - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV 


Define the remaining nodes. 

DEFINE NODE 21 NAME THRUSH 

DEFINE NODE 22 NAME LARK 


Define parameters for line/circuit UNA-0. 

DEFINE LINE UNA-0 STATE ON 

DEFINE CIRCUIT UNA-0 STATE ON 


The object database does not need to be defined because it 
defaults to the standard list of objects known to VAX/VMS. 


Define transmitter-related logging parameters. 
DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 
DEFINE LOGGING MONITOR STATE ON 
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5.3.8.2 Configuring the X.25 Connector Node 

The following NCP commands build the X25-PROTOCOL and 
X25-SERVER databases for a multihost PSI node. Node ROBIN 
is configured as the VAX PSI multihost node connected to the 
PSDN named PSS. 


Set up the X.25 protocol module. 

DEFINE MODULE X25-PR0T0C0L NETWORK PSS 

Define the line used to communicate with the X.25 network. 
DEFINE LINE DUP-0 STATE ON 


Define the local DTE. 


DEFINE MODULE X25-PR0T0C0L - 

DTE 311111222333 - 
CHANNELS 2018-1546 - 
LINE DUP-0 


Define host destinations for incoming calls. 


DEFINE MODULE X25-SERVER - 

DESTINATION THRUSH - 
SUBADDRESS 1-10 - 
OBJECT 36 - 
NODE THRUSH 

DEFINE MODULE X25-SERVER - 

DESTINATION LARK - 
SUBADDRESS 11-20 - 
OBJECT 36 - 
NODE LARK 


5.3.8.3 Configuring the Host Nodes 

The NCP commands below build the X25-ACCESS and X25- 
SERVER databases on nodes THRUSH and LARK to allow both 
host nodes to access PSS through connector node ROBIN. 

Node THRUSH database 


Set up the X.25 access module. 


DEFINE MODULE X25-ACCESS - 

NETWORK PSS - 
NODE ROBIN 
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Define the destination on THRUSH. 


DEFINE MODULE X25-SERVER - 

DESTINATION JOE - 
SUBADDRESS 1-10 - 
OBJECT OBJONE 


Define the X.29 call handler. 


DEFINE MODULE X29-SERVER STATE ON 


Define the destination objects for incoming calls. 


DEFINE OBJECT OBJONE - 

FILE OBJSTUP.COM - 
USER PSIUSER - 
PASSWORD PSIUSER 


Node LARK database 



Set up the X.25 access module. 

DEFINE MODULE X25-ACCESS - 

NETWORK PSS - 
NODE ROBIN 


Define the destination on LARK. 


DEFINE MODULE X25-SERVER - 

DESTINATION JOE - 
SUBADDRESS 11-20 - 
OBJECT OBJTWO 


Define the X.29 call handler. 


DEFINE MODULE X29-SERVER STATE ON 


Define the destination object for incoming calls. 


DEFINE OBJECT OBJTWO - 

FILE OBJTWO.COM - 
USER JIM - 
PASSWORD JIM 
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5.4 System Configuration Guidelines 

Proper network operation, particularly in a routing 
environment, requires that you properly configure the system 
software running on each node in the network. Memory and 
processor time are two principal resources that you need to 
define. 


5.4.1 Normal Memory Requirements 

Most of the memory required by the network software is 
allocated from the VAX/VMS nonpaged dynamic memory 
pool. This pool is configured by setting the NPAGEDYN, 
IRPCOUNT, LRPCOUNT, and LRPSIZE system parameters. 

These SYSGEN parameters are set by the AUTOGEN facility 
when the operating system is first booted and do not normally 
require modification. If, however, you find that the SYSGEN 
parameters must be reset to properly tune the system, run 
SYS$SYSTEM:SYSGEN, as shown in the following example, 
and change the parameter values. 

$ RUN SYS$SYSTEM:SYSGEN 
SYSGEN> USE CURRENT 
SYSGEN> SHOW/MAJOR 


SYSGEN> SET NPAGEDYN number 
SYSGEN> SET IRPCOUNT number 
SYSGEN> SET LRPCOUNT number 
SYSGEN> SET LRPSIZE number 
SYSGEN> SHOW/MAJOR 


SYSGEN> WRITE CURRENT 
SYSGEN> EXIT 

$ 
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5.4.1.1 NPAGEDYN Parameter 

To increase the nonpaged dynamic pool space, calculate the 

value for the SYSGEN parameter NPAGEDYN using the 

following equation. 

number = current value + a + b + c + d + 14000 

current value Is the current byte count without any version 

of DECnet-VAX installed (derived from the 
SYSGEN command SHOW/MAJOR). 

14000 Is the total number of bytes required to load 

the XM (DMC-11) driver (4000 bytes) and 
NETDRIVER (10000 bytes). If you need other 
drivers (DMP, DMF, Cl), the total should be 
higher (8000 bytes for the DMP; 11,000 bytes 
for the DMF; 3000 bytes for the Cl; 11,000 
bytes for the XE (DEUNA). 

a Is the total number of bytes required for all 

lines used by DECnet-VAX. Use the following 
formula to determine the approximate space 
required. 

a - (number of lines) * (number of buffers) * (buffer size) 


The buffer size and the number of buffers 
are determined by the values you give to 
the executor BUFFER SIZE and individual line 
RECEIVE BUFFERS parameters. 

b Is the total number of bytes required for the 

DECnet-VAX data structure that handles 
logical links. Use the following equation to 
determine the approximate space required, 
b = 512 * number of links 

The number of links is determined by the value 
you give to the executor MAXIMUM LINKS 
parameter. 
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c Is the total number of bytes required for the 

DECnet data structure that handles circuits. 
Use the following equation to determine the 
approximate space required. 

c = 60 * number of circuits 

The number of circuits is the number of 
circuits you intend to use. 

d Is a multiple of the additional IRPCOUNT count. 

Use the following equation to determine this 
value. 

d = (new IRPCOUNT - current IRPCOUNT) * 96 


The new IRPCOUNT is computed as in 
Section 5.4.1.2; the current IRPCOUNT is 
the current count without any version of 
DECnet-VAX installed. 

Use the NCP SHOW EXECUTOR and SHOW CIRCUITS 
commands to display parameter values that you have set for 
the local node. 


5.4.1.2 IRPCOUNT Parameter 

With the SYSGEN command SET IRPCOUNT, increase the 
number of preallocated I/O request packets to reflect the 
increase of nonpaged dynamic pool space using the following 
formula. 

number = current value + number of buffers + maximum circuits + 2 


current value 

number of 
buffers 

number of 
circuits 


Is the current count without any version of 
DECnet-VAX installed. 

Is the number of buffers that may be used 
by DECnet-VAX in peak periods (see 
Section 5.4.1.1). 

Is the number of circuits that you intend to 
use. 


5.4.1.3 LRPCOUNT and LRPSIZE Parameters 

Calculate the value for the SYSGEN parameter LRPCOUNT 
according to the following formula: 

number of buffers = number of lines + number of receive buffers 
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5.4.2 


The number is the total number of receive buffers specified for 
all lines plus the total number of lines. 

The value for LRPSIZE should match that of the BUFFER SIZE 
parameter in the executor database. 

Refer to the VAX/VMS Utilities Reference Volume for a complete 
discussion of the System Generation Utility (SYSGEN). Note 
that the new settings for LRPCOUNT and LRPSIZE will not 
take effect until the next time the operating system is booted. 


Critical Routing Node Requirements 

For some critical routing nodes in large networks, it may be 
necessary to guarantee that user processes running on the node 
never interfere with the memory requirements of the network 
software. In this case, you may want to configure the system 
for worst-case use of the nonpaged dynamic pool. 

The use of nonpaged pool is controlled by the quota values 
that you specify for each user when you create the user's 
authorization record. For worst-case configuration, the sum 
of the quotas of all the simultaneously active processes must 
provide the required free pool for the network software. 

To configure a system for such a worst case, adhere to the 
following four rules: 

• The sum of the ASTLM (asynchronous system trap limit), 
BIOLM (buffered I/O limit), DIOLM (direct I/O limit), and 
TQELM (timer queue Limit) quotas for each process must be 
added to the IRPCOUNT parameter. 

• The FILLM (file and logical link limit) quota for each process 
must be doubled and added to the IRPCOUNT parameter. 

• The ENQLM (enqueue limit) quota for each process must be 
doubled and added to the IRPCOUNT parameter. ENQLM 
is the number of locks each process can own. 

• The BYTLM (buffered I/O byte count limit) quota for each 
process must be added to the NPAGEDYN parameter. 
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Given these guidelines, the result of the calculation below 
should be less than the total free pool after the network has 
initialized: 

USERPROCESSES * (((ASTLM + BIOLM + DIOLM + TQELM ♦ (FILLM * 2)) * 96) + BYTLM) 

For example, if for a critical routing node you also want to 
provide for 16 users processes, the calculation might be: 

16 * (((10 + 6 + 6 + 5 ♦ (8*2)) * 96) + 4096) = 16 * 8224 = 131684 bytes 

This calculation indicates that there should be at least 131,584 
bytes of nonpaged dynamic pool remaining after the network 
has initialized. However, because it is extremely unlikely that 
all users will require their quota of pool at the same time, then, 
except for a worst-case configuration, the quotas and pool could 
be configured minimally so that no one user's quota would 
completely deplete the free pool. Use the SHOW MEMORY 
operator command or the dynamically updated POOL display 
for the Monitor Utility to configure the nonpaged dynamic 
memory pool for normal use. 

The consequences of running almost or completely out of pool 
are fairly obvious to system users: System performance will 
be very sluggish; processes will continually enter the MW AIT 
scheduling state while they wait for an available free pool; and 
the free pool SHOW MEMORY display will indicate almost 
none. 

If the lack of pool causes the network software on the node to 
be unable to allocate a buffer fast enough to receive data from 
a communications line, the line may be considered unusable by 
another node in the network. When this happens, the network 
will attempt to adaptively reconfigure itself, thereby resulting in 
network traffic consisting of configuration update messages. If 
the node with pool problems should be close to failing, without 
failing completely, it may alternate between working and not 
working, thereby causing the network to repeatedly reconfigure 
itself. Ultimately, these reconfigurations will degrade the 
performance of the entire network. 
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5.4.3 



CPU Time Requirements 

Proper system configuration to provide adequate processor time 
for the network software is somewhat more straightforward. 
Most of the procedures that control network routing are located 
in NETDRIVER. Because most of NETDRIVER runs at elevated 
interrupt priority level (IPL), normal user programs cannot 
preempt its execution. However, user-written drivers and 
privileged programs running at elevated IPL can affect the 
proper operation of NETDRIVER. 

The Guide to Writing a Device Driver for VAX/VMS provides 
guidelines for elevated IPL execution programming. In general, 
a program should run at elevated IPL only as long as necessary 
to synchronize correctly with other processes and devices. In 
particular, running at IPL IPL$_SYNCH for more than a few 
hundred milliseconds or running at any IPL at or above IPL$_ 
MAILBOX for more than a few hundred milliseconds may 
adversely affect the network software. The effect of improper 
elevated IPL programming on the whole network is the same 
as having insufficient free nonpaged dynamic pool. 

The procedure that handles the automatic network 
reconfiguration for a network node is contained in the NETACP 
process. Therefore, for proper network operation, the NETACP 
process must also be assured of sufficient processor time. It runs 
at base priority of 9, which is well above the recommended base 
priority of 4 for normal users. However, real-time processes 
running at priorities 10 through 31 can preempt the execution 
of NETACP. 

Just as for user-written drivers, the programming of real¬ 
time processes must account for the needs of the network 
software and other system software. A rule of thumb for 
real-time processes is that they should not normally preempt 
the execution of NETACP for more than a few hundred 
milliseconds at a time, and they should never preempt its 
execution for more than 5 to 10 seconds. This restriction allows 
NETACP sufficient processor time to run its routing algorithms 
properly. 

If NETACP is unable to perform all of its functions, the effects 
on the whole network will be the same as having insufficient 
free pool or incorrect elevated IPL programming. If the above 
guidelines cannot be met for a particular real-time application. 
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5.4.4 


the application should probably not be used on a node that is 
also doing network routing. 

The NETACP process, like all system processes, can be 
swapped and paged. However, because its base priority is 
9, it will be one of the last processes swapped when it is 
running and swapping becomes necessary. Also, NETACP 
receives high priority for paged disk I/O requests. Again, 
improper considerations for the disk I/O needs of NETACP 
can adversely affect the network as a whole. If the NETACP 
process continually enters the PFW or COMO scheduling state, 
it is probably not receiving sufficient priority for paging or 
swapping; other real-time or system programs should probably 
be modified to relieve the problem. 


UNIBUS Adapter Map Register Considerations 

The UNIBUS adapter on VAX processors provides a mechanism 
called UNIBUS map registers (UMRs) that allows UNIBUS 
peripherals to access VAX main memory. These map registers 
are required because the UNIBUS allows only 18 bits of 
address space while the VAX processors provide 24 or 30 bits 
(depending on processor type). The 18 bits of address space is 
divided into 496 pages of 512 bytes each. Therefore, there are 
496 map registers that allow up to 496 pages of memory to be 
mapped for direct memory access (DMA) by UNIBUS devices. 

Because UNIBUS map registers are a limited resource 
needed for correct operation of the network software, some 
consideration should be given to their use. 

VAX/VMS provides a service for device drivers to allocate and 
deallocate map registers. Most drivers allocate map registers 
only for the time it takes for the device to perform a transfer, 
after which they deallocate them for use by another I/O request 
to the same device or by other drivers for different devices. 
This type of allocation is referred to as dynamic allocation. 

Other drivers, however, permanently allocate map registers all 
the time the system is running. This is either because certain 
memory tables must be accessible to the device (TS11, DMC11, 
and DMP11) all the time the device is initialized or because 
of certain throughput requirements of the device (1 Megabaud 
DMC11/DMR11, DMP11, DEUNA, and LPA11). This type of 
allocation is referred to as permanent allocation. 
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If a device driver process attempts to allocate UMRs and there 
are not enough free to satisfy the allocation, the driver process 
is put into a FIFO wait queue to wait for UMRs to become 
available. 

The following list presents the UNIBUS map register 
requirements of the various supported UNIBUS devices. 

• The TS11 driver permanently allocates a maximum of three 
map registers in its command table for each TS11 on the 
UNIBUS when it initializes. The TS11 supports one DMA 
I/O request at a time, and because an I/O can be up to 
65,536 bytes in size, the TS11 driver requires a maximum of 
128 map registers that can be allocated dynamically. 

• The RL02, RK06, RK07, and RX02 disk drives support 
one DMA I/O request at a time. Because the maximum 
I/O request size can be 65,536 bytes, these drivers require 
a maximum of 128 map registers that can be allocated 
dynamically. 

• The LPA11-K laboratory data acquisition device driver can 
be configured to permanently or dynamically allocate up to 
496 map registers. The SYSGEN parameter LAMAPREGS 
allows you to specify how many map registers are to be 
permanently allocated; if this parameter is zero, map 
registers will be dynamically allocated as needed when 
the device is used for I/O. 

• The DMC11/DMR11 driver permanently allocates a 
maximum of three map registers for its base table when 
it initializes. It also permanently allocates enough map 
registers for all of its receive buffers, which are set with 
the RECEIVE BUFFERS line parameter and BUFFER 
SIZE executor parameter. However, if more than seven 
receive buffers are specified per line, only seven sets of map 
registers per line will be allocated. 

The DMC11/DMR11 driver supports one DMA transmit 
at a time and because each transmit can be a maximum of 
16,383 bytes in size, the DMC11/DMR11 driver requires 
a maximum of 32 map registers that can be allocated 
dynamically. 

• The DMP11 driver allocates map registers in the same way 
that the DMC11/DMR11 driver does with the exception 
that the DMP11 driver, which does not have a base table, 
requires three fewer map registers. 
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• The DEUNA device driver assigns eight receive buffers with 
a length of 1500 bytes per buffer. Enough map registers are 
permanently allocated for all receive buffers. 

The following example details how one might determine 
whether sufficient map registers will be available. Assume 
the example system consists of a VAX-11/780 with a single 
UNIBUS adapter, two RK07 disk drives on a single controller, 
a TS11 tape drive, and three DMRlls. The BUFFER SIZE 
executor parameter is set to 576 and each line has its RECEIVE 
BUFFERS parameter set to 4. Because each buffer can 
potentially cover three pages (two pages to contain the 576- 
byte buffer and one page for an offset page) and because the 
VAX/VMS map register allocator always allocates an extra 
invalid map register for protection, each buffer will require four 
map registers. 


Device 

Permanent Map Registers 

TS11 

Three permanent map registers would be required 
for the TS11. 

DMR11 (3) 

Fifty-seven map registers would be required 
for the three DMR1 Is. (Each DMR permanently 
allocates 19 map registers; three UMRs for the 
base table and four UMRs for each of the four 
receive buffers.) 


Therefore, 496 minus 60, or 436 map registers are available for 
dynamic use by all devices. 

Because the TS11 and RK07s can each be using 128 map 
registers, there will always be at least 436 minus 256, or 180 
map registers available to map DMR11 transmit buffers. This 
amount is more than sufficient as the DMRlls will each have 
only one transmit of 576 bytes outstanding at a time, which 
will require a maximum of 3 times 4, or 12 map registers. 

In general, because VAX/VMS has dynamic map register 
allocation and waiting when UNIBUS map registers run out, 
they are not a resource problem. However, if a system has 
a large number of DMC11/DMR11, DMP11, and DEUNA 
devices, it is prudent to calculate map register use to ensure 
that the configuration works. 
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Installation of a Network 


This chapter describes how to start DECnet-VAX and how to 
install and start VAX PSI. 


6.1 Installing a DECnet-VAX Key 

If you have purchased a license for either a DECnet-VAX 
full function kit or a DECnet-VAX end node kit, you must 
install the key for the license. The procedure for installing the 
appropriate license key is described in the DECnet-VAX Key 
Installation Guide , which is distributed with the key. 

The DECnet-VAX full function kit allows the node on which 
it has been installed to be configured as either a routing node 
or an end node. The end node kit allows the node to be 
configured only as an end node. 


6.2 Bringing Up Your Network Node Using 
STARTNET.COM 

After you satisfy the prerequisites for establishing a network 
and define the necessary parameters in the configuration 
database (see Chapter 5), you are ready to bring up your 
DECnet-VAX node. To do so, you must have defined the local 
node (using the DEFINE EXECUTOR command) in the perma¬ 
nent database. This information is the minimum requirement 
for the initial control of the operational state of the node. 

After you build the permanent database using either NCP or 
the NETCONFIG.COM interactive configuration procedure (see 
Chapter 5), issue the following command to bring up your 
network: 

$ QSYSSMANAGER:STARTNET.COM 
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This command starts NCP and NML, and configures the 
volatile database with the parameters that you have defined 
in the permanent database. This procedure also turns on the 
local node and all lines and circuits connected to it. In addition, 
STARTNET.COM starts the network command terminal ACP 
by executing SYS$MANAGER:RTTLOAD.COM. At this point, 
the local node is ready for network operations with itself and 
with adjacent nodes. 

DECnet-VAX uses OPCOM to display certain network-related 
messages on the network operator's console. When you turn on 
the local node, OPCOM will display the following message: 

Opcom, hh:mm:ss:cc, SYSTEM Acct= 

Opcom, DECnet starting 


Once you have brought up your DECnet-VAX node, you use 
NCP commands to control the operational states of network 
components. You can control both local components and 
remote executions of NCP commands. This control allows you 
to dynamically reconfigure your network to control the use of 
the network and its resources. Use the NCP commands CLEAR 
and SET for the volatile database to control the network. 

Parameters in the permanent database define network com¬ 
ponents each time you use the ALL keyword with the SET 
command. Typically, you will use the SET "component" ALL 
command if you choose not to use STARTNET.COM to bring 
up the network. Section 6.5 discusses how you can shut down 
your network in an orderly manner. 

Note that VAX PSI Access software should have been installed 
on the host node before invoking STARTNET.COM if the node 
will be a part of a multihost PSI network. This is described in 
the VAX PSI Installation Procedures. 
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6.3 Bringing Up Your VAX PSI DTE 

Bringing up VAX PSI DTE is similar to bringing up a node on 
the DECnet-VAX network. First, install VAX PSI, following 
the procedure described in the VAX PSI Installation Procedures. 
Make sure you configure VAX PSI in multihost mode (instead 
of native mode) if you are building an Ethernet network that 
allows some or all of its nodes to access the PSDN(s) connected, 
The multihost installation will set up the commands necessary 
to bring up the connector node (the node connected to the 
PSDN(s)) as a DTE. (Section 5.3 includes examples of both 
native mode and multihost mode configurations.) 

Invoking the STARTNET.COM procedure will bring up both 
DECnet-VAX and VAX PSI software. Once you are satisfied 
that VAX PSI is installed properly, you can use VAX PSI to 
communicate with a remote DTE over a packet switching data 
network (PSDN). 

Note that if you make changes to your PSI system while it 
is running and you wish to include these changes in your 
PSI system the next time the system is started, you must also 
make similar changes to the permanent database using NCP 
commands (DEFINE and PURGE). 


6.4 Testing the Installation with UETP Test Procedure 

To ensure that the DECnet-VAX installation is successful, 
you can use the User Environment Test Package (UETP) to 
test DECnet. The test procedure is described in the Guide to 
VAX/VMS Software Installation. 


6.5 Shutting Down Your DECnet-VAX Node 

Bringing down your operating system will automatically bring 
down your DECnet-VAX node as well. The next time you 
reboot the operating system, your network will come up 
automatically if SYSTARTUP.COM invokes STARTNET.COM 
(see Section 6.2). However, if the network is running and you 
want to shut down your network node in an orderly manner 
or otherwise restrict its use, you can use NCP to control the 
operational state of the local node. NCP offers three options for 
shutting down the executor node. 
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• To shut down your local node without destroying active 
logical links, use the command 

NCP>SET EXECUTOR STATE SHUT 

This command closes the node in an orderly fashion; new 
links are not allowed, and existing links are not destroyed. 
When all logical links are disconnected, this command turns 
off the node, and NCP logs an event message. 

Once the last link terminates and is disconnected, the 
executor node in the SHUT state enters the OFF state. This 
action occurs whether or not the node is currently in use 
for route-through traffic. Consequently, the communication 
path between nodes using the local node for route-through 
may be broken. 

• Instead of shutting down your local node, you can restrict 
network operations on that node. This restriction does not 
affect current logical link activity; however, no new inbound 
logical links can be created unless they originate locally 

or unless a process with the OPER privilege confirms them. 
Use the following command to restrict local node operations: 

NCP>SET EXECUTOR STATE RESTRICTED 

• To shut down the local node regardless of current logical 
link activity, use the command 

NCP>SET EXECUTOR STATE OFF 

This state allows no new logical links to be created, termi¬ 
nates existing links, and stops route-through traffic. 

Note: Programs that have declared names or object numbers 
and that are started independently of DECnet-VAX 
should be programmed to terminate when their mail¬ 
boxes receive a MSG$_NETSHUT message. This message 
appears when the node is shutting down. 

Whenever the local node's state goes to OFF, DECnet-VAX 
uses the OPCOM facility to display the following message on 
the console: 

Opcom, hh:mm:ss:cc, SYSTEM Acct= 

Opcom, Decnet shutting down 
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Table 6-1 summarizes local node states and basic network 
operation restrictions for them. These operations include 
network routing, confirming inbound connections from a 
remote node, and initiating outbound connections to a remote 
node. 

If your network configuration includes VAX PSI, shutting down 
a DECnet-VAX node will also shut down VAX PSI and clear 
the PSI volatile database. Bringing up the DECnet-VAX node 
subsequently will restart VAX PSI and re-create the volatile 
database from the permanent database. 


Table 6-1 

Local Node States and Network Operations 

State 

Route-Through 

Traffic 

Connect Confirm 
Operations 

Connect Initiate 
Operations 

ON 

Unrestricted 

Unrestricted 

Unrestricted 

RESTRICTED 

Unrestricted 

Unrestricted only 
if the partner 
node is the local 
node or it the 
confirming 
process has the 

OPER privilege 

Unrestricted 

SHUT 

Unrestricted 

Unrestricted only 
if the confirming 
process has the 

OPER privilege 

Unrestricted only 
if the initiating 
process has the 
OPER privilege 

OFF 

Restricted 

Restricted 

Restricted 
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NCP provides several kinds of tests to help you determine 
whether the network is operating properly. Specifically, 
these tests let you exercise network software and hardware 
by sending data through various network components and 
then returning that data to its source. After you have started 
DECnet-VAX software, you may want to run some of these 
tests. 


In general, problems that you encounter with the DECnet-VAX 
network will probably arise from misconfigured VAX/VMS and 
DECnet parameters, which can be easily fixed with SYSGEN 
or NCP. DIGITAL supplies variations of these tests to exercise 
separate layers of the network. User-written processes or 
DECnet-supplied processes may also initiate the tests. 


DECnet-VAX tests fall into two categories: node-level loopback 
tests and circuit-level loopback tests. Use node-level tests 
to evaluate the operation of logical links, routing, and other 
network-related software. Use circuit-level tests to evaluate the 
operation of circuits. It is suggested that you use node-level 
tests first, then, if necessary, use circuit-level tests. This chapter 
describes these variations as they relate to DECnet loopback 
capabilities and the NCP command LOOP, and provides a 
practical approach to their use. 

VAX PSI provides various ways to analyze software and hard¬ 
ware operation and to diagnose problems in PSI operations. 

Use line-level loopback tests to evaluate the operation of the 
X.25 physical lines and communications hardware. Use the 
tracing facility to record the flow of packets and frames, and 
the trace analyzer to analyze this data. VAX PSI provides an 
additional facility for the KMS-11 line interface, allowing you 
to dump the microcode to a specified file for analysis. This 
chapter describes these VAX PSI test facilities and how to use 
them. 
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7-1 Node-Level Tests 

Node-level loopback tests will test the logical link capabilities 
of a node by exchanging test data between DECnet processes in 
two different nodes or between DECnet processes in the same 
node. These tests consist of two types: 

• Loopback tests for logical link operation irrespective of the 
circuit 

• Loopback tests for operation over a specified circuit 

The second test sends test messages over a specified circuit 
associated with a loop node name (see Section 7.1.2). This test 
directs test messages regardless of the Routing layer function. 

Both types of node-level loopback tests allow you to test the 
functions of your DECnet-VAX software. To test various 
aspects of this software, you may want to perform a series of 
operations, which are described below. 

1 In the first test, loop information to a remote loopback 
mirror process using a remote loopback test. This tests all 
local and remote network software up to the DNA user layer 
on the remote node. 

2 If the first test fails, use a loop node name and loop informa¬ 
tion to the local node and to a remote node. The loop node 
name allows you to direct traffic over a specified circuit, 
which tests local and remote Routing software. 

3 If the second test fails, set the circuit's line to "controller 
loopback" and repeat step 2. 


Regardless of the type of test you choose, use the NCP com¬ 
mand LOOP NODE to send test messages. This NCP function 
uses a cooperating process called the Loopback Mirror to facili¬ 
tate the transmission and reception of test messages. When you 
issue this command, you have the option of controlling the type 
of binary information (MIXED, ONES, ZEROS); the number of 
blocks of information, which ranges from 1 to 65,535; and the 
length in bytes of each block to be looped, which also ranges 
from 1 to 65,535. (It is recommended that you use a maximum 
block length of 4096 bytes to reduce the system load.) Refer to 
the NCP section in the VAX/VMS Utilities Reference Volume for 
the complete syntax of the LOOP NODE command. 
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If your message returns with an error, the test stops and NCP 
prints a message that indicates a test failure, specifies the reason 
for the failure, and provides a count of the messages that were 
not returned. For a summary of NCP error messages, refer 
to the VAX/VMS System Messages and Recovery Procedures 
Reference Manual. 

In the example below, the test attempted to send 10 mes¬ 
sages, each 50 bytes long. The first two messages were sent 
successfully, and an error occurred on the third. 

NCP>L00P NODE BOSTON COUNT 10 

'/.NCP-I-NMLRSP, listener response- line communication error 
Messages not looped = 8 


7.1.1 Remote Loopback Test 

Use the LOOP NODE command to test for a logical link 
connection between two nodes. When using this command, 
you must identify the node to which you want to loop test 
messages. Figure 7-1 illustrates a remote loopback test. 

For this test, you first turn the selected remote node line and 
circuit to the ON state to allow for logical link activity. Then 
use the LOOP NODE command. For example, the set of 
commands below tests both local and remote DECnet software 
on nodes BOSTON and TRNTO. 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>L00P NODE TRNTO COUNT 10 
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Figure 7-1 Remote Loopback Test 


NCP Commands: 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>LOOP NODE TRNTO COUNT 10 


BOSTON (executor) TRNTO 



ZK-555-81 


7.1.2 Local and Remote Loopback Tests Using a Loop 

Node Name 

If the remote loopback test failed, then use the LOOP NODE 
command with a loop node name to test a logical link path 
over a specified circuit. You can loop test messages either over 
a logical link path and circuit within the local node or between 
two different nodes with a loop node specified for the circuit 
to be used. Use the latter method first in order to test remote 
Routing layer software. In each case, use the SET NODE 
command with the CIRCUIT parameter to establish a loop node 
name. For example, the following command establishes circuit 
DMC-0 as the circuit over which loop testing will take place: 

NCP>SET NODE TESTER CIRCUIT DMC-0 

No other parameters are valid for loop nodes. This circuit must 
be turned on when performing these tests. 

Note that you cannot assign two loop node names to the same 
circuit. For example, once you establish TESTER as the loop 
node name for circuit DMC-0, you must issue a CLEAR NODE 
TESTER CIRCUIT command before assigning another loop 
node name to DMC-0. 
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7.1.2.1 


When a logical link connection request is made to the loop 
node name, all subsequent logical link traffic will be directed 
over the associated circuit. The destination of the traffic is 
whatever node address is associated with the loop node name. 
The loop node name is necessary because, under normal 
operation, DECnet Routing software selects which path to use 
when routing information. The loop node name overrides 
the routing function so that information can be routed over 
a specific circuit. To remove the association of the loop node 
name with a circuit, use the CLEAR NODE CIRCUIT or CLEAR 
NODE ALL command, as in the following command: 

NCP>CLEAR NODE TESTER CIRCUIT 

A loop node name specified with the SET NODE CIRCUIT 
command may be used for any network traffic (for example, 
COPY requests or application program traffic). The loopback 
node name appears as a valid node name in the network for all 
purposes. 


Local-to-Remote Testing 

To test a logical link path over a circuit between the local node 
and a remote node, you must specify a loop node name for the 
given circuit and issue the LOOP NODE command. Figure 7-2 
illustrates a local-to-remote loopback test using a loop node 
name. 

For this test, you first turn on the line and set a loop node 
name for the given circuit to the remote node. Next, turn on 
the circuit. Finally, issue the LOOP NODE command using the 
loop node name, as shown in the following example: 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET NODE TESTER CIRCUIT DMC-0 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>LOOP NODE TESTER COUNT 10 

This set of commands tests both local and remote Routing layer 
software operation. The test messages are looped over the 
loopback circuit. Because the test actually tests the operation 
of the Routing layer on the remote node, the message may not 
come back on the circuit over which it was sent. 
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Figure 7-2 Local-to-Remote Loopback Test Using a Loop Node 
Name 


NCP Commands: 

NCP>SET LINE DMC-0 STATE ON 
NCP>SET NODE TESTER CIRCUIT DMC-0 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>LOOP NODE TESTER COUNT 10 


BOSTON (loop node TESTER) Remote Node 



ZK-556-81 


7.1.2.2 Local-to-Local Testing 

If the local-to-remote test fails, try a local loopback test with 
the local node to test local Routing layer software exclusively. 
To test a logical link path over a specified line on the local 
node, specify a loop node name and set the device controller to 
loopback mode. Figure 7-3 illustrates a local-to-local loopback 
test using a loop node name. 
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Figure 7-3 Local-to-Local Loopback Test Using a Loop Node 
Name 


NCP Commands: 


NCP>SET LINE DMC-0 STATE OFF 

NCP>SET LINE DMC-0 CONTROLLER LOOPBACK 

NCP>SET LINE DMC-0 STATE ON 

NCP>SET CIRCUIT DMC-0 STATE ON 

NCP>SET NODE TESTER CIRCUIT DMC-0 

NCP> LOOP NODE TESTER COUNT 10 LENGTH 32 


BOSTON (loop node TESTER) 



NCP 



r 

NML 




Loopback 

Mirror 


(logical link) 


Controller 
(in loopback) 


ZK-557-81 


For this test, you first turn off the line, set the controller to 
loopback mode, and turn on the line and circuit. Finally, set a 
loop node name for the given line and issue the LOOP NODE 
command using the loop node name. The set of commands 
below tests the Routing layer software and the controller on the 
local node. 


NCP>SET LINE DMC-0 STATE OFF 
NCP>SET LINE DMC-0 CONTROLLER LOOPBACK 
NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>SET NODE TESTER CIRCUIT DMC-0 
NCP>L00P NODE TESTER COUNT 10 LENGTH 32 
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Because the device is set to loopback mode, the test messages 
are looped over the circuit and back to the local node. If 
this test fails, try a local loopback test to test local DECnet 
software. 

Note: Because of restrictions in the operation of the DMC con¬ 
troller, you must use a block length of fewer than 50 bytes 
for controller loopback tests. 


7.1.3 Local Loopback Test 

If the loopback tests described in Section 7.1.2.2 should fail, 
then use either the LOOP NODE command with the local 
node-id or the LOOP EXECUTOR command to test local 
DECnet software. This type of test uses DECnet-VAX software 
to loop messages to the loopback mirror on the local node. 
Figure 7-4 illustrates a local loopback test. 

Figure 7-4 Local Loopback Test 


NCP Commands: 

NCP>LOOP EXECUTOR COUNT 10 


BOSTON (executor) 



ZK-558-81 


For this test, you simply issue the following command at the 
local node: 

NCP>L00P EXECUTOR COUNT 10 
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This test evaluates the local DECnet software using an internal 
logical link path. If this test succeeds and the other node¬ 
level tests fail, then try the circuit-level tests. If these tests 
fail, the executor's default DECnet account is probably set up 
incorrectly. 


7.2 Circuit-Level Tests 

Circuit-level loopback tests will test a DECnet circuit by looping 
test data through a hardware loopback device on the circuit, 
either through a modem (or loopback connector) or through a 
remote node. The tests that use a hardware loopback device 
are referred to as controller loopback tests; the tests that use 
a loopback connector or a modem are referred to as circuit 
loopback tests; the tests that use the software capabilities of the 
system are referred to as software loopback tests. 

You may want to perform a series of operations to test various 
aspects of a circuit. These operations are described below. 

1 In the first test, perform a software loopback test to another 
node to determine whether the circuit is operational up to 
the remote circuit unit and controller. 

2 If the first test fails, set the controller to loopback mode 
and use a controller loopback test to determine whether the 
controller works. 

3 If the second test succeeds, then attach a modem (or loop- 
back connector) to the controller and use a circuit loopback 
test to determine whether the unit is functional. 


Regardless of the test type, you must use the NCP command 
LOOP CIRCUIT to perform a circuit-level loopback test. When 
you issue this command, you have the option of controlling 
the type of binary information (MIXED, ONES, ZEROS); the 
number of blocks of information, which ranges from 1 to 
65,535; and the length in bytes of each block to be looped, 
which also ranges from 1 to 65,535. (It is recommended that 
you use a maximum block length of 4096 bytes.) For the 
complete syntax of the LOOP CIRCUIT command, refer to the 
NCP section in the VAX/VMS Utilities Reference Volume. 
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7.2.1 


If your message returns with an error, the test stops and 
NCP prints a message indicating a test failure, the reason 
for the failure, and a count of the messages that were not 
returned. For a summary of NCP error messages, refer to the 
VAX/VMS System Messages and Recovery Procedures Reference 
Manual. In the example below, the test attempted to send 10 
messages, each 50 bytes long. The first two messages were sent 
successfully, and an error occurred on the third. 

NCP>SET LINE DMC-0 CONTROLLER NORMAL STATE ON 
NCP>L00P CIRCUIT DMC-0 COUNT 10 

'/.NCP-I-NMLRSP, listener response- line protocol error 
Messages not looped = 8 


Software Loopback Test 

Use the LOOP CIRCUIT command to perform a software 
loopback test of a circuit connected to the local node. This type 
of test uses DECnet-VAX software to loop through the circuit 
to circuit service software in the adjacent node and back to the 
local node. Figure 7-5 illustrates a software loopback test to 
test whether the circuit is operational up to the remote unit and 
controller on the adjacent node. 

In the first step of this test, you turn the line off. Next, you set 
the controller to its normal operational mode and put the line 
and the circuit in the ON state. Finally, you issue the LOOP 
CIRCUIT command. This sequence is shown below. 

NCP>SET LINE DMC-0 STATE OFF 
NCP>SET LINE DMC-0 CONTROLLER NORMAL 
NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>L00P CIRCUIT DMC-0 COUNT 10 

This set of commands tests the circuit DMC-0 up to the adja¬ 
cent node. If this test fails, try a circuit loopback test to verify 
that the circuit is functional. 
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Figure 7-5 Software Loopback Test 


NCP Commands: 

NCP>SET LINE DMC-0 STATE OFF 
NCP>SET LINE DMC-0 CONTROLLER NORMAL 
NCP>SET LINE DMC-0 STATE ON 
NCP>SET CIRCUIT DMC-0 STATE ON 
NCP>LOOP CIRCUIT DMC-0 COUNT 10 


BOSTON (executor) Remote Node 



NCP 




’ 

' 


Remote 
Circuit Service 
Software 


NML 



. ~""J 



(not a logical link) 




ZK-559-81 



7.2.2 Controller Loopback Test 

Use the LOOP CIRCUIT command to perform a controller 
loopback test of a physical line on the local node while the con¬ 
troller is in loopback mode. This type of test verifies whether 
or not the circuit up to the controller and the controller itself 
are functional. Figure 7-6 illustrates a controller loopback test. 

For this test, you first turn the line off. Next, you set the 
controller to loopback mode and put the line and circuit in the 
ON state. Finally, you issue the LOOP CIRCUIT command. 

For example: 

NCP>SET LINE DMC-0 STATE OFF 

NCP>SET LINE DMC-0 CONTROLLER LOOPBACK 

NCP>SET LINE DMC-0 STATE ON 

NCP>SET CIRCUIT DMC-0 STATE ON 

NCP>L00P CIRCUIT DMC-0 COUNT 10 LENGTH 32 
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Figure 7-6 Controller Loopback Testing 


NCP Commands: 

NCP>SET LINE DMC-0 STATE OFF 

NCP>SET LINE DMC-0 CONTROLLER LOOPBACK 

NCP>SET LINE DMC-0 STATE ON 

NCP>SET CIRCUIT DMC-0 STATE ON 

NCP>LOOP CIRCUIT DMC-0 COUNT 10 LENGTH 32 


BOSTON (executor) 


NCP 


Controller 
(in loopback) 


ZK-561 -81 


NML 

J 




This set of commands tests the circuit up to the controller for 
physical line DMC-0 connected to the local node by circuit 


DMC-0. 


Note: Because of restrictions in the operation of the DMC con¬ 
troller, you must use a block length of fewer than 50 bytes 
for controller loopback tests. 


7-12 


























Testing the Network 


7.2.3 Circuit-Level Loopback Testing 

Circuit-level loopback testing is also supported for Ethernet 
circuits. One major difference between loopback testing on 
point-to-point and multipoint circuits (DMCs and DMPs) and 
on an Ethernet circuit is that the former requires two separate 
processors (one at each end), but the latter requires only one 
processor. In Ethernet circuit loopback testing, it is the target 
node's Ethernet interface rather than its processor that loops the 
messages. 

In Ethernet circuit-level loopback testing (as in the case of 
point-to-point loopback testing), network management accesses 
the Data Link layer directly, thus bypassing intermediate layers. 
One advantage of the Ethernet loopback test is that it can be 
performed concurrently with other DECnet operations on the 
circuit. 


7.2.3.1 Testing With the PHYSICAL ADDRESS and NODE 

Parameters 

To be tested, an Ethernet circuit must be in the ON state and 
the SERVICE parameter must be set to ENABLED. Note that, 
by default, the SERVICE parameter is set to DISABLED for 
Ethernet circuits. As indicated in Chapter 2, DECnet supports 
the UNA, which provides for multiaccess connections between 
many nodes on the same Ethernet circuit. In the example 
below, the command identifies the circuit device UNA and the 
controller number 0 for an Ethernet circuit. 

NCP>SET CIRCUIT UNA-0 STATE ON SERVICE ENABLED 

The UNA is used to loop messages on the Ethernet circuit. If 
desired, it can be used to loop messages to itself in order to test 
its own state. To do this, enter the following commands: 

NCP>SET LINE UNA-0 STATE OFF 

NCP>SET LINE UNA-0 CONTROLLER LOOPBACK STATE ON 
NCP>SET NODE TEST CIRCUIT UNA-0 
NCP>LOOP NODE TEST 


In this case you were able to test the status of the UNA in 
controller loopback, but not the capacity of the node to transmit 
and receive messages. For more information on the node's 
capacity to send and receive messages, see Section 7.1.2.2. 
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More typical cases of loopback testing of Ethernet circuits 
involve looping messages to remote systems over the Ethernet; 
this tests the capability of both the local and the remote UNAs 
to send and receive messages. In those cases, you are required 
to supply such information as the Ethernet physical address or 
the node name or address of the circuit at the remote node that 
you wish to test. 

Nodes on Ethernet circuits are identified by unique Ethernet 
addresses. An Ethernet address is 48 bits in length and is repre¬ 
sented by six pairs of hexadecimal digits (6 bytes), separated by 
hyphens (for example, AA-01-23-45-67-89). For more detail 
on Ethernet addresses, see Section 3.3.3. 

Each UNA on the Ethernet circuit has a hardware address 
(in read-only memory) that has been assigned to it by the 
manufacturer. Typically, DECnet will set an Ethernet physical 
address for the UNA, thereby replacing the hardware address as 
the address to which the UNA currently responds. The UNA's 
physical address will continue to be the address to which it 
responds, unless it is reset to the hardware address value (for 
example, if the Ethernet circuit is set to OFF). 

It is helpful to know the Ethernet physical address of the UNA 
on the remote node that you wish to test. Since this is not 
always possible, it is a good practice if you plan to perform 
loopback tests to include the hardware address of each of the 
UNAs on your Ethernet circuit in the permanent database, 
thus ensuring that the address will be retrievable from the 
volatile database. You can then use the node-id in the LOOP 
command. When node-id is specified, network management 
software retrieves the hardware address from the volatile 
database and attempts to transmit the loop message to the 
remote UNA by alternately using the hardware address and the 
physical address that DECnet would normally use. 

The following example contains an Ethernet physical address: 

NCP>LOOP CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-FF-04 



Since in this case you know the physical address of the remote 
node that you wish to test, you merely include the PHYSICAL 
ADDRESS parameter with its value. If, however, that physical 
address had changed (for example, if it had been reset to the 
hardware address value), the loopback would have failed. You 
would have received the following message: 
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'/.NCP-I-NMLRSP, listener response line protocol error 
Messages not looped=l 


If you also know the name or address of the remote node, 
you could test the UNA on that node even though its Ethernet 
physical address may have changed. The Ethernet hardware 
address of the node to be tested must already have been 
entered in the database on the executor node. If the hardware 
address had been included in the volatile database, and you 
test by supplying the node name or address, the loop test will 
be attempted by the network management software to both the 
hardware address and the DECnet address. 

An example of a loopback test that specifies the NODE param¬ 
eter is the following: 

NCP>LOOP CIRCUIT UNA-0 NODE TEST 

Assume that TEST'S physical address, which had previously 
been AA-00-04-00-F7-04, was changed. Thus any attempt 
to test TEST by way of that physical address would not have 
succeeded. If, however, TEST'S hardware address (which 
was AA-00-03-00-01-31) had been included in the volatile 
database on the executor node, the loopback test that included 
the NODE parameter in its specification would have succeeded. 

In the above example, you could alternatively have supplied 
the node address value (such as 226) for the NODE parameter. 
For example, if you knew the node-id but did not know the 
name of the node, you could have specified 

NCP>L00P CIRCUIT UNA-0 NODE 226 

In this case, the node address is used to construct the DECnet 
physical address and the Ethernet hardware address (assuming 
that it had been included in the volatile database) is used 
to access the circuit on the remote node and complete the 
loopback test. Thus it is important to enter the hardware 
addresses in the volatile database. 

If you want to examine the Ethernet hardware address of 
your own UNA (in this case UNA-0), you can use the NCP 
command SHOW LINE CHARACTERISTICS. When you enter 
the command 

NCP>SHOW LINE UNA-0 CHARACTERISTICS 
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You will receive the following display: 

Line Volatile Characteristics as of 15-APR-1984 15:33:25 
Line = UNA-0 


Receive buffers 
Controller 
Protocol 
Service timer 
Hardware address 
Buffer size 


0 

normal 

Ethernet 

4000 

AA-00-03-00-12-00 
1498 


7.2.3.2 Loopback Assistance 


DECnet supports the use of an assistant physical address and 
an assistant node to aid you in interrogating a remote node. To 
use this feature, you specify either the ASSISTANT PHYSICAL 
ADDRESS parameter or the ASSISTANT NODE parameter as 
an additional parameter to the LOOP CIRCUIT command. 

You can use the "assistant" in three distinct ways. First, you can 
use it to assist you in receiving loop messages from a remote 
node. Second, you can use it in transmitting loop messages 
to a remote node. Third, you can use it in both transmitting 
messages to and receiving messages from a remote node. 

There are various reasons why you might choose one form of 
assistance over another. For example, it is possible that the 
target node to which you wish to transmit a message is located 
at a point where the signals are too weak to send a message. 

In this case, you could request assistance in transmitting the 
message to the target node. Similarly, you may be able to 
transmit messages to the target node, but not be able to receive 
messages from it. In such a case you can send a message 
directly to the target node and request an "assistant" to aid 
you in receiving a message from the target node. When you 
encounter difficulties in both sending and receiving messages, 
you can request an assistant node to help you to both transmit 
messages to and receive messages from the target node. 

The commands below illustrate the use of the ASSISTANT 
PHYSICAL ADDRESS and ASSISTANT NODE parameters. 

NCP>L00P CIRCUIT UNA-0 PHYSICAL ADDRESS AA-00-04-00-18-04- 
_ ASSISTANT PHYSICAL ADDRESS AA-00-04-00-15-04 

NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE THRUSH 
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In the first command, you are requesting the node described 
by the Ethernet physical address AA-00-04-00-15-04 to assist 
you in testing the node described by the Ethernet physical 
address AA-00-04-00-18-04. In the second command, you 
are requesting the node THRUSH to assist you in testing node 
LOON. 

If you specify either the ASSISTANT PHYSICAL ADDRESS 
or ASSISTANT NODE parameter and you do not specify the 
HELP parameter, you will receive FULL assistance; that is, 
you will be assisted both in the receiving and transmitting of 
loop messages. Note that because, in the above examples, the 
ASSISTANT PHYSICAL ADDRESS and ASSISTANT NODE 
parameters were specified without the HELP parameter, the 
default is FULL assistance. 

If you wish to use an assistant node only to receive messages 
from the remote node, you could issue the following command: 

NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE THRUSH HELP RECEIVE 

In this example you are requesting the node THRUSH to assist 
you in receiving messages from node LOON. When you wish 
to be assisted only in sending or transmitting loop messages, 
you could issue a command such as the following: 

NCP>L00P CIRCUIT UNA-0 NODE LOON ASSISTANT NODE 21 HELP TRANSMIT 

Note that in this case the ASSISTANT NODE parameter 
contains the node address, rather than the name of the node as 
in the previous example. In each of the last two examples, the 
HELP parameter was included to specify the type of assistance 
desired. 


7.3 X.25 Line-Level Loopback Tests 

There are three types of line-level loopback tests that you can 
use to test an X.25 physical line: 

• External loopback tests that loop data back through the 
modem 

• Internal loopback tests that loop data back through the 
device 


External loopback tests that loop data back through a 
loopback device on the line 
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You may want to perform the series of operations below to test 

various aspects of the physical line. 

1 First, using the loop switch on the modem, perform an 
external loopback test through the modem. This test checks 
the logic of the device transmitter and receiver, the line 
driver, the modem cable, and part of the modem. If this test 
is successful and you still have errors, contact your network 
manager. 

2 If the first test fails, perform an internal loopback to test 
only the logic of the device transmitter and receiver. 

3 If the second test succeeds, attach a hardware loopback 
device to the modem cable. Then perform an external 
loopback to test the logic of the device transmitter and 
receiver, the line driver, and the modem cable. 


Regardless of the test type, use the NCP command SET LINE to 
specify the type of loopback test and the NCP command LOOP 
LINE to initiate the line-level loopback test. 

Specify values for two parameters of the SET LINE command, 
as follows: 


Internal Loopback 

External Loopback 

STATE SERVICE 

STATE SERVICE 

CONTROLLER LOOPBACK 

CONTROLLER NORMAL 


Note that the line state must be set to OFF before the CON¬ 
TROLLER parameter can be changed. 

To initiate a test, use the LOOP LINE command with the same 
line identifier you specified with the SET LINE command. For 
example, the commands below initiate an external loopback test 
for the line DUP-0: 

NCP>SET LINE DUP-0 ... STATE SERVICE CONTROLLER NORMAL 
NCP>LOOP LINE DUP-0 ... 

Associate parameters with the LOOP LINE command to control 
the type of test information and the size and number of blocks 
sent during testing. 


7-18 









Testing the Network 


Use the COUNT and LENGTH parameters to specify the 
number of blocks sent over the line during a test and the length 
of each block (in bytes) sent. The command line below sends 
2000 blocks 100 bytes long over the line. 

NCP>L00P LINE DUP-0 COUNT 2000 LENGTH 100 ... 

Specify decimal integers in the range 1 to 65,535 for both 
these parameters. Note that this test will take approximately 5 
minutes, as calculated below. 

2000 * (100+4)*8 

- seconds = 5 minutes 

5000 

A DUP runs at 5000 bps when looped back. 

Use the WITH parameter to specify the type of binary informa¬ 
tion sent during loopback testing. You can specify three types 
of binary information: 

ONES All binary ones 

ZEROES All binary zeros 

MIXED A random combination of ones and zeros 

For example, the command below sends 2000 blocks 100 bytes 
long, each containing all binary ones, over the line: 

NCP>L00P LINE DUP-0 COUNT 2000 LENGTH 100 WITH ONES 

If you omit a qualifier to the WITH parameter or omit the 
parameter itself, a combination of ones and zeros (MIXED) 
is sent. If you omit the COUNT and LENGTH parameters, 
one block of 128 bytes is sent. For example, the command 
below sends one block of 128 bytes, containing mixed binary 
information, over the line: 

NCP>L00P LINE DUP-0 
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7.4 Tracing 

The tracing facility can be used only for VAX PSI. This facility 
records activity between the local DTE and DCE. Records are 
created for transmitted and received packets and frames at 
X.25 levels 2 and 3 respectively, and are placed in one or more 
specified files. X.25 level 2 defines link-access procedures, and 
X.25 level 3 defines packet-level procedures. 

You can enable and disable tracing, specify where tracing 
takes place, and designate the output file by means of the 
NCP command SET MODULE X25-TRACE. For a complete 
description of tracing, including an explanation of how to 
use NCP commands to perform tracing, refer to the VAX PSI 
Management Utilities Manual. 

The X.25 Trace Analyzer (PSIXTA) processes a file (or set of 
files) of trace records that have been created by the tracing 
facility. Through the use of command lines, PSIXTA allows you 
to process these records and select, format, and print only the 
trace records you require for your particular trace analysis. 

For a description of the PSIXTA utility program, refer to the 
VAX PSI Management Utilities Manual. 


7.5 Dumping KMS-11 Microcode 

This section describes how to dump the KMS-11 microcode 
to a file and how to analyze the dump file. The KMS-11 
is a synchronous line interface combined with X.25 level 2 
microcode, and is supported by VAX PSI (see the table of 
DECnet circuit and line devices in the NCP section of the 
VAX/VMS Utilities Reference Volume). 

Use the MICROCODE DUMP parameter of the NCP command 
SET LINE to dump the microcode of the specified KMX or KMY 
device to the file indicated. By default, the output file takes the 
format below, where filename is the file that you specify. 

filename.DMP 


For example, the command below dumps the microcode of the 
file BARRY.DMP in your current default directory: 

NCP>SET LINE KMX-0-0 MICROCODE DUMP BARRY 
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Use this parameter only if you believe there is an error in the 
microcode of the KMX or KMY. The KMS-11 Dump Analyzer 
(PSIKDA) processes a dump file created by the NCP command 
SET LINE with the MICROCODE DUMP parameter. Through 
the use of command lines, PSIKDA allows you to process this 
file and select, format, and print only the parts of that dump 
you require. 

For a description of the PSIKDA utility program, refer to the 
VAX PS1 Management Utilities Manual. 
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Performing Network User 
Operations 


DECnet-VAX allows you to perform a variety of operations 
over the network. For example: 

• Retrieving information about the status of the nodes in your 
network 

• Establishing communication with a remote DECnet node 
through the heterogeneous command terminal facility 

• Accessing files on remote nodes 

• Performing task-to-task operations 

This chapter describes each of these operations. The primary 
focus of this chapter, however, is on the use of task-to-task 
communication in network operations. 


8.1 Retrieving Network Status Information 

Before you perform a specific type of operation over the net¬ 
work, you may want to check the status or availability of a 
particular node or nodes in your network. To retrieve such in¬ 
formation, you can use the DCL command SHOW NETWORK. 

Note that the SHOW NETWORK command can be used to 
retrieve information about your network only if your local node 
is a routing node. If your local node is a nonrouting (end) node, 
you will not receive any network information; instead, you will 
be directed to a designated routing node. 

The SHOW NETWORK command displays the availability of 
the local node as a member of the network and the addresses 
and names of all nodes that are currently accessible to the local 
node. 

The SHOW NETWORK command also displays link and cost 
relationships between the local node and other nodes in the 
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network. It displays the current network in terms of five 
characteristics: node, links, cost, hops, and next hop to node. 


Node 

Identifies each available node in the 
network by its node address and node 


name. 

Links 

Shows the number of logical links be¬ 
tween the local node and each available 


remote node. 


Shows the total line cost of the path to 
a remote node. The cost for each line in 
the network is assigned by the system 
manager. 

Shows the number of intermittent nodes 
plus the target node. 

Shows the outgoing physical line used to 
reach the remote node. (The local node is 
identified by the term LOCAL.) 

When you enter the SHOW NETWORK command, you will 
receive the following display on your terminal: 


Cost 

Hops 

Next hop to node 


VAX/VMS Network Status for local node 2.161 ARAKIS on 15-APR-1984 
The next hop to nearest area router is node 2.62 ZEUS. 


Node 

Links 

Cost 

Hops 

Next Hop 

to 

Node 

2.161 ARAKIS 

0 

0 

0 

Local 

-> 

2.161 ARAKIS 

2.1 RAEL 

0 

8 

1 

UNA-0 

-> 

2.1 RAEL 

2.2 PANGEA 

0 

8 

1 

UNA-0 

-> 

2.2 PANGEA 

2.3 TWDEE 

0 

10 

2 

UNA-0 

-> 

2.63 AURORA 

2.4 TWDUM 

0 

8 

1 

UNA-0 

-> 

2.4 TWDUM 

2.11 NEONV 

0 

8 

1 

UNA-0 

-> 

2.11 NEONV 

2.63 AURORA 

0 

8 

1 

UNA-0 

-> 

2.63 AURORA 


Total of 7 nodes. 


If your local node is an end node, and you enter the SHOW 
NETWORK command, you will receive the following message 
on your terminal: 


This is a nonrouting node, and does not have any network 
information. The designated router for node ARAKIS is 
node 2.62 ZEUS. 

If you enter the SHOW NETWORK command, but the network 
is unavailable at that time, you will receive the following 
display. 

Network unavailable 
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For more detailed information on the DCL command SHOW 
NETWORK, see the description in the VAX/VMS DCL 
Dictionary. 


8.2 Establishing Communication with Remote Nodes 

DECnet-VAX supports a command terminal facility that per¬ 
mits a single user to establish communication with a remote 
node and to use the facilities of that system while physi¬ 
cally connected to the local node. By means of this link, you 
can temporarily become a local user of the remote node and 
thereby perform functions that the remote node allows its local 
users to perform. 

Note that in addition to communicating with remote VAX/VMS 
nodes, you can also communicate with non-VAX/VMS nodes 
that support the DNA heterogeneous remote command terminal 
protocol facility. Consult the Software Product Description for 
non-VMS operating systems and their DECnet 
implementations. 

If you wish to use the command terminal facility to establish 
communication with a remote node, enter the DCL command 
SET HOST. The format for this command is 

$ SET HOST nodename 

The nodename is a 1- to 6-character name or number specifying 
the remote node at which you want to log in. You can use 
node numbers that do not include area numbers. 

The remote node system will prompt for a username and 
password. If the information you supply is valid, you will be 
logged in to the remote node. To return control to your local 
node, type LOGOUT. 

You will receive the following message at your terminal: 

‘/.REM-S-END, Control returned to node _nodename: : 

This message indicates that control has been returned to your 
local node. 

The only special control character used for remote command 
terminal operations is CTRL/Y. Except for CTRL/Y, all control 
characters are handled as if they were issued at the local node. 
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Repeated, rapid pressing of CTRL/Y will generate a prompt 
asking if the remote connection should be broken. If you 
answer "Yes" to the prompt, control will return to the local 
node. This technique is useful if for some reason you cannot 
return to the local node properly. 

The following command sequence illustrates the operation of 
remote command terminals for our network topology example. 
The name of the local node is BOSTON. 

$ SET HOST TRNTO 
Username: SMITH 
Password: 

Welcome to VAX/VMS Version 4.0 on node TRNTO 


$ LOGOUT 

SMITH logged out at 8-MAY-1984 12:31:55:49 
'/.REM-S-END, Control returned to node .BOSTON:: 
$ 


Once you are logged in at a remote node, you can use the 
SET HOST command to establish communication with another 
node. After logging in to node TRNTO, you could type SET 
HOST DENVER. 

You would again be prompted for a username and password. If 
you then supply a valid username and password, you will be 
logged in at node DENVER. 

Note that when you log out at node DENVER, control is 
returned to node TRNTO. You must log out from node TRNTO 
to return to your local node, BOSTON. 

For more detailed information on the SET HOST command, see 
the description in the VAX/VMS DCL Dictionary. 
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8.3 Accessing Files on Remote Nodes 

DECnet-VAX allows you to access files on remote nodes in 
your network as though these files were on your local node. 
You can use the DECnet-VAX facilities to access remote files by 
means of DCL commands and command procedures, higher- 
level language programs, and MACRO programs using VAX 
RMS or VAX/VMS system services. 


8.3.1 Using DCL Commands and Command Procedures 

Most DCL commands used to perform file operations at a local 
node can also be used to perform these operations on remote 
nodes. For example, you can use the same DCL commands to 
obtain directory listings, manipulate files, and execute command 
procedures on remote nodes. You need only prefix a node 
name followed by two colons to the standard VAX/VMS file 
specification to access the remote file. 

For example: 

$ TYPE TRNTO::W0RK$:[DOE]LOGIN.COM 

In this example, the TYPE command requests that the file 
LOGIN.COM in the directory DOE at the remote node TRNTO 
be displayed on your local terminal. 

As with DCL, remote file accessing by higher-level languages is 
accomplished in a way that is transparent to the user. All that 
you need to specify is the name of the remote node containing 
the file or files that you wish to access. Like DCL, higher-level 
language programs also employ the VAX RMS services to 
perform file access operations. 

Other examples of the use of DCL commands to access remote 
files can be found in the VAX/VMS DCL Dictionary. Command 
descriptions in that document also include restrictions that 
apply to individual commands and command qualifiers used 
over the network. Unless otherwise stated, you can assume that 
a particular DCL command is supported for network operations. 
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8.3.2 


8.3.3 


Using Higher-Level Language Programs 

You can use various higher-level languages to write programs 
that access remote files. Regardless of the programming lan¬ 
guage used, you access remote files exactly as you would access 
local files. 

For example, assume you want to design a FORTRAN program 
to transfer files from a local node to a remote node. Also 
assume that the two nodes are identified by the logical names 
SRC and DST, respectively. You can use two DCL commands 
to define the logical names for the files involved in the transfer, 
by entering the following commands: 

$ DEFINE SRC TRNTO::USER:[STOCKROOM.PAPER]INVENTORY.DAT 
$ DEFINE DST BOSTON::LPAO: 

Once you have made the logical name assignments, the FOR¬ 
TRAN program can open the files by way of those logical 
names. You can use the following FORTRAN open calls: 

OPEN (UNIT=1.NAME='SRC 1 .TYPE=•OLD'.ACCESS='SEQUENTIAL'. 

FORM='FORMATTED') 

OPEN (UNIT=2.NAME='DST'.TYPE='NEW'.ACCESS='SEQUENTIAL'. 

FORM='FORMATTED',CARRIAGECONTROL='LIST', 

RECORDTYPE='VARIABLE') 

This FORTRAN program uses standard I/O statements to 
transfer records from one file to another. In this example, the 
access mode is sequential. 

Examples of complete higher-level language programs designed 
to access remote files are included in the appropriate sections of 
each VAX language's programming manuals. 


Using MACRO Programs 

The VAX/VMS system provides a programming interface for 
remote file accessing, using VAX MACRO. The MACRO pro¬ 
grams can use VAX Record Management Services (RMS) calls 
or VAX/VMS system service calls. This section describes how 
RMS can be used to access remote files. The VAX/VMS system 
services, which can also be used for remote file accessing, are 
described more thoroughly in Section 8.5.4. 
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For remote file processing, RMS integrates the network software 
necessary to translate standard RMS calls, which provides a 
transparent user interface to the network. 

Using the RMS facilities, you can perform remote file-handling 
operations on entire files or access individual records, through 
programmed RMS service calls in a VAX/VMS MACRO appli¬ 
cation. All you need to do is supply the name of the remote 
node in your file specification. 

As in the FORTRAN example above, you can use DCL com¬ 
mands to make logical name assignments to the source and 
destination files that you wish to manipulate. 

$ DEFINE SRC TRNTO::USER:[STOCKROOM.PAPER]INVENTORY.DAT 
$ DEFINE DST BOSTON::TEMP:[ARCHIVE]INVENTORY.DAT 

Before you can open either the source (SRC) or destination 
(DST) files with the RMS $OPEN statement, however, you 
must allocate the appropriate file access blocks (FABs) and 
record access blocks (RABs) in your program. To do this you 
can use the RMS structures shown below. 


SRC.FAB: 


$FAB 

FAC=GET,- 
F0P=SQ0.- 
FNM=SRC 

$RAB 

FAB=SRC_FAB,- 
RAC=SEQ.- 


These statements define the source file FAB and RAB control 
blocks. You must also define the destination file FAB and RAB 
control blocks. 
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DST.FAB 

$FAB FAC=PUT,- 
FOP=SQO,- 
FNM=DST,- 
0RG=SEQ,- 
RFM=VAR,- 
RAT=CR 

DST.RAB 

$RAB FAB=DST_FAB,- 
RAC=SEQ,- 


After defining the source and destination FABs and RABs, you 
can now open the files for remote file processing. Note that if 
your program accesses files sequentially, you can specify the 
sequential-only (SQO) option of the file options (FOP) field of 
the FAB. Specifying FOP=SQO enables RMS and the remote 
File Access Listener (FAL) to enter into file-transfer mode, 
which significantly increases file-transfer performance. 

Examples of complete MACRO programs using RMS to access 
remote files are contained in the Guide to VAX/VMS File 
Applications. Examples in this document also illustrate the 
network-specific features provided by VAX RMS. 

RMS fields and options that must be specified for DECnet- 
VAX applications are described in the VAX Record Management 
Services Reference Manual of the VAX/VMS System Routines 
Reference Volume. This manual also describes restrictions that 
apply to using RMS over the network. See Chapter 9 for a list 
of restrictions on VAX/VMS operations involving other systems 
in a heterogeneous network. 

Note that DECnet-VAX does not support the use of RMS for 
operations on a remote magnetic tape volume. 
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8.4 Performing Task-to-Task Operations 

Task-to-task communication, a feature common to all DECnet 
implementations, allows two programs running under the same 
or different operating systems to communicate with each other 
regardless of the programming languages used. For example, a 
FORTRAN program running on the VAX/VMS system at node 
BOSTON could exchange messages with a MACRO program 
running on the RSX-11M system at node DALLAS. Although 
these programs use different programming languages and 
run under different operating systems, the DECnet software 
translates system-dependent language calls into a common 
set of network protocol messages. Note that in the context of 
task-to-task communication, the terms "task" and "program" are 
used synonymously. 


8.4.1 Transparent and Nontransparent Task-to-Task 

Communication 

DECnet-VAX supports both transparent and nontransparent 
task-to-task communication. Transparent communication pro¬ 
vides all the basic functions necessary for a DCL command 
procedure or a user program (written in either VAX/VMS 
MACRO or in a higher-level language) to communicate with 
other command procedures or user programs over the net¬ 
work. Nontransparent communication allows the MACRO 
programmer to use more network-specific functions. 

A simple analogy illustrates the differences between these two 
forms of communication. Transparent communication is similar 
to device-independent I/O in VAX/VMS in which you move 
data with little concern for the way the operation is accom¬ 
plished. Likewise, transparent communication allows you to 
move data across the network without necessarily knowing that 
you are using DECnet software. Nontransparent communica¬ 
tion, on the other hand, is analogous to device-dependent I/O, 
in that you are interested in specific characteristics of the device 
that you want to access. A nontransparent task, in turn, can 
use network-specific features to monitor the communication 
process. 
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8.4.1.1 Transparent Communication 

Transparent communication provides the basic functions nec¬ 
essary for a task to communicate with another task over the 
network. These functions include the initiation and completion 
of a logical link connection, the orderly exchange of messages 
between both tasks, and the controlled termination of the 
communication process. To perform these functions, you can 
program your transparent task in any of the higher-level lan¬ 
guages supported over the network, in VAX MACRO (using 
RMS service calls or system service calls) or even using DCL 
commands. 

One way to view transparent communication is to look at the 
programming required to develop such an application. Trans¬ 
parent access provides the minimum functions necessary to 
communicate over the network using standard I/O opera¬ 
tions. When accessing the network transparently, you use no 
DECnet-specific calls to perform these functions; rather, you use 
standard RMS I/O service calls or the normal I/O statements 
provided by the applicable language to access a sequential 
record-oriented device. (The remote task is modeled as two 
VAX/VMS mailboxes in which two processes can perform read 
and write operations.) You can also use system service calls to 
perform transparent communication, as described in Section 8.5. 


8.4.1.2 Nontransparent Communication 

Nontransparent communication provides the same basic func¬ 
tions as transparent communication plus additional system 
service and I/O functions supported by DECnet-VAX. In par¬ 
ticular, a nontransparent task can create and use a VAX/VMS 
mailbox to receive information that would otherwise remain 
inaccessible to a transparent task. Thus you can make use of 
network-specific features such as optional user data on connects 
and disconnects, and interrupt messages. Also, certain non¬ 
transparent tasks that have a mailbox can receive and process 
multiple inbound connection requests. 

In general, nontransparent tasks can use a mailbox to receive 
information about particular network operations. Mailbox 
messages are of four types: 

• Messages that result from the use of certain system service 
calls (including optional user data carried on logical link 
creation or termination) 

• Interrupt messages 
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8.4.2 


• Logical link status messages 

• Network system messages 

Nontransparent functions that indirectly cause mailbox mes¬ 
sages to be placed in the receiver's mailbox include calls for 
initiating and completing logical links, and calls for termi¬ 
nating links. Figure 8-1 illustrates the use of mailboxes by 
nontransparent tasks. 

A nontransparent task can also receive network status notifi¬ 
cations in the mailbox. These notifications apply to physical 
and logical link conditions over the network. For example, 
DECnet-VAX software can notify a nontransparent task of the 
following conditions: 

• Third-party disconnections 

• Network software and hardware related problems 

• Processes exiting before I/O completion 

• Connection request timeouts 

Regardless of whether you are performing a transparent or 
nontransparent task-to-task operation, you must use a task 
specification string to identify the remote task with which you 
wish to communicate. 


Task Specification Strings in Task-to-Task 
Applications 

A task specification string is a quoted string that identifies the 
remote task to which you attempt a logical link connection. 

To establish a logical link connection with a remote task 
addressed as object type 0, use either of the following forms of 
task specification string: 

• "TASK=taskname" 

• "0=taskname" 

Note that "0" and "TASK" are equivalent. The taskname can be 
from 1 to 16 characters. 
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Figure 8-1 Mailbox Messages 


Nontransparent 

Task 



(Network Task) 


Nontransparent 

Task 


Mailbox 


Mailbox 





Synchronous Disconnect (opt. user data) 


Disconnect Abort (opt. user data) 


A MSG$ DISCON 
MSG$ ABORT 




DECnet-VAX Software 


Network Status Notifications: 

MSG$_EXIT 

MSG$ PATHLOST 

MSG$_PROTOCOL 

MSG$ TIMEOUT 

MSG$_THIRDPARTY 

MSG$ NETSHUT 


ZK-840-82 


If the remote node is a VAX/VMS system, the taskname rep¬ 
resents the file name of a command procedure to be executed 
at the remote node. (If the remote node is not a VAX/VMS 
system, the maximum length of the taskname may be different.) 
The command procedure can complete the logical link itself 
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(using a DCL OPEN command), or it can include a DCL RUN 
command to execute a program that completes the logical link. 

The examples that follow illustrate two uses of the task spec¬ 
ification string. The specification below identifies the task 
TEST2 by using the TASK= form for specifying remote tasks. 
The second example is the same as the first, except that access 
control information is provided and the alternative 0= form for 
specifying a task is used. 

BOSTON::"TASK=TEST2" 

BOSTON"SMITH JOHN"::"0=TEST2" 

In this example, TEST2 refers to SYS$LOGIN:TEST2.COM 
at the remote VAX/VMS node. Note that only the file name 
component of the command file specification is used in the task 
name string. 


8.4.3 Functions Required for Performing Task-to-Task 

Operations 

Several functions are necessary for performing a task-to-task 
operation. The number of functions will, of course, depend 
on whether you intend to access the network transparently or 
nontransparently. 

Even a transparent task-to-task application requires a minimum 
number of operations to initiate and complete a logical link 
connection, to exchange messages, and to terminate the logical 
link. These operations are actually a subset of a larger group 
of functions defined for nontransparent communication. The 
entire set of functions is as follows: 

• Initiating a logical link connection 

— Requesting a logical link to a remote task 1 

— Declaring a network name and processing multiple 
connection requests 

• Completing a logical link connection 

— Rejecting a logical link connection request 
— Accepting a logical link connection request 1 

1 Minimum subset for transparent task-to-task communication. 
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• Exchanging messages 

— Sending and receiving data messages 1 
— Sending and receiving interrupt messages 

• Terminating a logical link 

— Synchronously disconnecting the logical link 
— Aborting the logical link 1 

Nontransparent tasks can use any or all of these functions 
to extend the basic capabilities offered under transparent 
communication. 


8.4.3.1 Initiating a Logical Link Connection 

Regardless of whether you access the network transparently 
or nontransparently, you must establish a communication 
link to the remote node on which the target task runs before 
any message exchange can take place. You establish the 
link by issuing a source task call that requests a logical link 
connection. (The source task is the task that initiates a logical 
link connection request; the target task is the task with which 
you want to communicate). 

The interaction between the source task and the target task 
that takes place before the logical link is established is called 
a handshaking sequence.) Upon receiving a call that requests 
a logical link connection, the local DECnet-VAX node initiates 
a handshaking sequence with the target task. The following 
information is supplied in a connection request: 

• An I/O channel. The I/O channel serves as the path 
over which messages are sent and received by the source 
program. 

• The identification of the target node. Every node in a 
network has an identifier that distinguishes it from all other 
nodes in the network. Transparent communication uses a 
task specification string to indicate the name of the target 
node. Nontransparent communication requires a user¬ 
generated data structure called the network connect block 
(NCB), which includes a task specification string. 

• An object type descriptor. 

• Access control information (optional). 

1 Minimum subset for transparent task-to-task communication. 
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• Optional user data. Nontransparent tasks have the option 
of sending up to 16 bytes of data to the target program (see 
the information below on NCBs). 

It is important to be aware that once you issue a call that uses 
either a task specification string or an NCB, you access the 
network and, by definition, DECnet-VAX software. 


8.4.3.2 Completing the Logical Link Connection 

As part of the handshaking sequence, the target task completes 
the logical link connection in two steps. First, the DECnet 
software at the remote node processes the inbound logical 
link connection request. Second, the target task either accepts 
or rejects the link. These steps are performed differently, 
depending on whether the target task uses transparent or 
nontransparent I/O. 

When a logical link request is received, a procedure called 
NETSERVER.COM is executed, which in turn invokes the 
image NETSERVER.EXE. This program works in conjunction 
with the network ACP (NETACP) and uses DCL to invoke the 
image or command procedure defined for the requested object 
(the specified task for object 0 or FAL for object 17). 

When the logical link is terminated, the "object" program (for 
example, FAL) also terminates. However, the process is not 
deleted. Instead, control is returned to NETSERVER.EXE, 
which communicates with NETACP to inquire for another 
incoming logical link request. This inquiry process continues 
until NETSERVER encounters a timeout condition (the default 
is 5 minutes). 

The time that NETSERVER waits for another logical link 
request can be specified by the system manager. The logical 
name NETSERVER$TIMEOUT, when defined, determines the 
amount of time NETSERVER will wait before reaching the 
timeout condition. Note that the equivalence name must be in 
the standard VAX/VMS delta time format. 

In the following discussion, it is assumed that the remote node 
is a VAX/VMS system. If the remote node on which your 
target task runs is not a VAX/VMS system, you should refer to 
the DECnet documentation for that system. 
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Completing the Connection Transparently 

If the target task is transparent, the DECnet software at the 
remote node checks the access control information supplied in 
the connection request call. 

Before you access the remote node, the system manager must 
have created the appropriate account in the UAF (refer to the 
information on access control). In addition, the command 
procedure file (taskname.COM) for starting the remote task 
must exist in the directory associated with the account identified 
by the access control information. For a description of the 
command procedure taskname.COM, see Section 8.7.1, which 
contains examples of command procedures designed for task- 
to-task communication. 

Command procedures for objects existing in the OBJECT 
database (which is created using NCP commands) are located in 
the SYS$SYSTEM directory. The DIGITAL supplied FAL.COM 
procedure is an example of such a command procedure. 

Completing the Connection Nontransparently 

If the target task is nontransparent, then one of several things 
may occur. If the task has not declared itself a network task 
(and is therefore eligible to accept only one connection request 
at a time), then the DECnet software at the remote node 
performs the access checking procedure. After it starts, the 
target task retrieves the connection information by translating 
the logical name SYS$NET using the $TRNLNM system service 
call (see Section 8.6). 

If the target task declares itself as an active network task, then 
DECnet-VAX software places all connection requests addressed 
to the task in the mailbox associated with the channel being 
used. The first message in the mailbox is the NCB from the 
original connection request that started the task. This message 
appears in the mailbox after channel assignment and name 
declaration occur. Once the task declares a network name 
or number, subsequent inbound connection requests are not 
checked by the remote node to verify access control. (Note that 
if the task is started without being part of a DECnet operation, 
access control is never checked.) Section 8.6 describes in more 
detail the nontransparent process of completing the logical link 
connection. 
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After examining the incoming connection request, the target 
task either accepts or rejects the request, and optionally can 
send 1 to 16 bytes of data back to the source task at the same 
time that it responds to the logical link connection request. 
Furthermore, a library routine, LIB$ASN_WTH_MBX, which 
assigns a channel and associates a unique mailbox, can be used 
when accepting the connection if no optional data is returned. 


8.4.3.3 Exchanging Messages 

You access the network transparently or nontransparently, 
DECnet-VAX sends data messages over a logical link in re¬ 
sponse to a set of send and receive calls issued by the source 
and target tasks. For higher-level language tasks, use standard 
READ and WRITE statements to send and receive data mes¬ 
sages. (In Example 8-2, the two FORTRAN tasks use read and 
write statements to exchange information. The equivalent RMS 
service calls are $GET and $PUT.) 

After DECnet-VAX creates a logical link, the two tasks are 
ready to exchange messages. This exchange can take place 
only if the two tasks "cooperate" in the transmission process. 

In other words, for each message sent by a task, the receiving 
task must issue a corresponding call to receive the message. 
Also, you must decide which task will disconnect the link. In 
addition, if the tasks are nontransparent, they must agree on 
whether or not the optional data will be passed. In the context 
of an established logical link, the task sending a message is the 
transmitter and the task receiving it is the receiver. 

DECnet-VAX distinguishes between two types of messages: 
data messages and mailbox messages. Data messages are 
the normal mode of information exchange for both transpar¬ 
ent and nontransparent communication. Mailbox messages 
such as interrupt messages, messages resulting from some 
DECnet operation (including optional user data), and net¬ 
work status notifications, can be used only in nontransparent 
communication. 

Nontransparent communication frequently involves using a 
mailbox to obtain network-specific information. A task may 
receive three types of messages in its mailbox: 
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• Messages that DECnet generates when the task initiates 
certain network operations. A VAX/VMS task issues system 
service calls to initiate these operations. 

— When one task requests a logical link connection, a 
notification message (and optional user data) may be 
placed in the mailbox of the target task. 

— When a target task accepts or rejects the logical link 
connection request, a notification message (and optional 
user data) is placed in the mailbox of the source task. 

— When one task synchronously disconnects or aborts a 
logical link, a notification message (and optional user 
data) is placed in the mailbox of the task from which it is 
disconnecting. 

• Network status notification messages that inform a task of 
some unusual network occurrence (such as a third-party 
disconnect). 

• Interrupt messages sent by the other task. 


8.4.3.4 Terminating the Communication Process 

The termination of a logical link signals the end of the commu¬ 
nication between tasks. 

In transparent communication using higher-level language 
statements, RMS service calls, or system service calls, either 
task can break the link. To terminate the link properly, it is 
recommended that the receiver, and not the transmitter, of the 
final message issue the close call to break the link. The link 
termination process is complete when the other task issues a 
link termination request. In transparent communication using 
system service calls, the $DASSGN system service call causes 
the link to be terminated. 

In nontransparent communication using system service calls, 
you can terminate I/O operations over a channel in one of 
three ways: 

• Synchronous Disconnect ($QIO) —Indicates to the remote 
receiver that all messages sent by the local transmitter have 
been acknowledged at the end-communication layer. This 
does not guarantee, however, that the user of NSP received 
the data. 
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• Disconnect Abort ($QIO) —Indicates to the remote receiver 
that all messages sent have not necessarily been received. 

To ensure that all messages are received before the link is 
disconnected, the sender must cancel I/O on the channel 
before issuing the abort call. 

• Deassign Channel and Terminate Link ($DASSGN)— 

Deassigns the channel and immediately breaks the link. 

Note that after either a synchronous disconnect or a disconnect 
abort, you can issue a new connection request because you 
did not deassign the I/O channel but merely deaccessed the 
link. For further information on these system service calls, see 
Section 8.6. 

When a nontransparent task terminates the communication 
process, a notification message indicating that the link is 
disconnected is placed in the mailbox of the affected task. 

A nontransparent task can send up to 16 bytes of optional user 
data, which is also placed in the mailbox. 

By their nature, disconnect operations are of little value in 
guaranteeing to both partners that communication is complete. 
Therefore, it is recommended that the communicating tasks 
agree on a protocol for terminating communication. In general, 
the receiver, not the transmitter, of the final message should 
disconnect the logical link. 

In general, transparent communication allows you to create a 
logical link between tasks, send and receive data messages, and 
terminate the logical link at the end of the message dialog. The 
discussion covers general concepts implicit in DECnet-VAX 
task-to-task communication and assumes familiarity with the 
QlO-related material in the VAX/VMS System Services Reference 
Manual. The use of higher-level language statements and 
RMS service calls in transparent task-to-task communication is 
described in Section 8.5. 


8-19 






Performing Network User Operations 


8.5 Performing Transparent Task-To-Task Operations 

This section describes the system service calls and functions that 
you can use to perform transparent task-to-task communication 
over the network. You can perform these operations using any 
of the following methods: 

• DCL commands and command procedures 

• Higher-level language programs using appropriate language 
calls 

• MACRO programs using VAX RMS calls or VAX/VMS 
system service calls 

See Section 8.7 for examples of transparent task-to-task opera¬ 
tions. 


8.5.1 Using DCL Commands and Command Procedures 

To perform transparent task-to-task operations, you can use 
DCL commands to construct and execute command procedures. 

For example, to display information about another system, you 
can design a command procedure that can be invoked as a 
remote task. Assume that a procedure called SHOWBQ.COM 
is designed to return status information about jobs entered in 
batch queues on the system where it executes. Assume also 
that SHOWBQ.COM resides on node TRNTO. You can use 
SHOWBQ.COM for task-to-task communication by entering a 
task specification string in a TYPE command. For example: 

$ TYPE TRNTO"BROWN JUNE"::"TASK=SHOWBQ" 

See Section 8.7.1 for an example of a command procedure used 
for task-to-task communication. For additional information 
concerning the design, construction, and execution of command 
procedures, see the Guide to Using DCL and Command Procedures 
on VAX/VMS. 
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8.5.2 



Using Higher-Level Language Programs 

This section contains examples of higher-level language calls 
that can be used for transparent task-to-task communication. 
Each higher-level language call contains a task specification 
string as part of its statement. 


Higher-level language tasks can use standard file opening 
statements to request a logical link connection to a remote task. 
The following examples show how to specify a target task, 
TEST4, running on node TRNTO, in six languages supported 
on VAX/VMS. 


FORTRAN 

BASIC 

PL/I 

PASCAL 

COBOL 

C 


OPEN (UNIT=7 / NAME= / TRNTO:: ,, TASK=TEST4 ,,, / TYPE= , NEW') 

OPEN 'TRNTO: :"TASK=TEST4"' AS FILE #7 

OPEN FILE(OUTPUT) TITLE (TRNTO: :"TASK=TEST4"'); 

OPEN (PARTNER / , TRNTO:: ,, TASK=TEST4 ,,, / NEW); 

SELECT PARTNER ASSIGN TO "TRNTO:: ,,,, TEST=TASK4 ,,,,,, . 
OPEN OUTPUT PARTNER. 

F1=OPEN ("TRNTO: :""TASK=TEST4""",2); 


To complete the logical link, the target task performs a file 
opening operation using the logical name SYS$NET to establish 
a communications path back to the source task. The following 
examples show how to specify SYS$NET. 


FORTRAN OPEN (UNIT=2,NAME='SYS$NET , / TYPE='OLD') 

BASIC > OPEN "SYS$NET"AS FILE #2 

PL/I OPEN FILE(INPUT) TITLE ('SYS$NET'); 

PASCAL OPEN (PARTNER/SYSSNEnOLD); 

COBOL SELECT PARTNER ASSIGN TO "SYS$NET". OPEN 

INPUT PARTNER. 

C F2=OPEN ("SYS$NET",2); 


An example of a FORTRAN program designed for transparent 
task-to-task communication is in Section 8.7.2. 
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8.5.3 


Using RMS Service calls in MACRO Programs 

You can write a MACRO program or a higher-level program to 
perform transparent task-to-task communications, using RMS 
service calls. This section describes how to use RMS service 
calls in a MACRO program. 

Note that the RMS $OPEN statement is equivalent to the 
higher-level language statements described in the previous 
section. 

Once the appropriate FAB and RAB control blocks have been 
defined, you can use the $OPEN statement to specify the target 
task, TEST4, running on node TRNTO. You can initiate the link 
by specifying the following call, in your MACRO program. 

TARGET: 

$FAB FAC=<GET,PUT>,- 

ORG=SEQ,- 

FNM=NODE::"TASK=TEST4" 

$OPEN FAB=TARGET 

To complete the logical link, the target task performs a file¬ 
opening operation using the logical name SYS$NET to establish 
a communications path back to the source task. For example: 

REQUESTER: 

$FAB FAC=<GET,PUT>,- 

ORG=SEQ,- 
FNM=SYSNET 

$OPEN FAB=REQUESTER 

As in the case of the target task, the appropriate FABs and 
RABs must already be declared, if the RMS OPEN call is to 
succeed. On inbound connections, DECnet-VAX automatically 
makes the logical name assignment to SYS$NET. 
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8.5.4 Using System Service Calls in MACRO Programs 

You can write MACRO programs or higher-level language 
programs to perform transparent task-to-task communications, 
using system service calls. This section focuses on MACRO 
programs using system service calls for performing these 
operations. 

Table 8-1 summarizes these calls and their network-related 
functions. Section 8.5.5 presents the format of these calls in 
more detail. 


Table 8-1 System Service Calls for Transparent Communication 


Call Function 

$ASSIGN Request a logical link connection 

$DASSGN Terminate a logical link 

$QIO (IO$_READVBLK) Receive a message 
$QIO (IO$_WRITEVBLK) Send a message 


These calls allow you to perform task-to-task communication 
in much the same way as you would perform normal I/O 
operations. Use the $ ASSIGN call to assign a logical link I/O 
channel to a device, which in this case is a task that behaves 
like a full-duplex record-oriented device. You can perform read 
and write operations with this task in either a synchronous or 
asynchronous manner. To exchange messages, use the Queue 
I/O (QIO) requests supported by DECnet-VAX. When all 
communication completes, use the $DASSGN system service 
call to deassign the channel and thereby disconnect the logical 
link. 
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8.5.4.1 Requesting a Logical Link 

To request a logical link and assign an I/O channel, use the 
$ASSIGN system service. When you issue this call, you must 
include a task specifier for the remote node on which the 
cooperating task runs. The task specifier identifies the remote 
node and the target task to which you want to establish a 
logical link. 

For example, for the network model described in Chapter 1, 
you could establish a logical link to target task TEST2 on node 
TRNTO to perform task-to-task communication. To create 
this link, code the following VAX MACRO statements in your 
source program. 

TARGET: .ASCID /TRNTO::"TASK=TEST2"/ 

NETCHAN: .BLKW 1 ; Channel number returned here 


$ASSIGN_S DEVNAM=TARGET.CHAN=NETCHAN 

For debugging or for symmetry, you can develop and run the 
target task on the local node. Use the local node name (or node 
number 0) plus two colons to connect to the local node. 

Once you establish a logical link, you refer to the assigned 
channel in any succeeding call in the MACRO program, either 
to send or receive messages, or to deassign the channel and 
terminate the logical link. 

Until the connection operation completes, the process is in 
local event flag wait (LEF) state in kernel mode. Therefore, 
pressing CTRL/Y will not return the process to DCL status. 

The maximum amount of time that the process will wait in 
this state is specified by the NCP command SET EXECUTOR 
with the OUTGOING TIMER parameter. If this timer cannot 
be set to an acceptable value, tasks that accept commands from 
the terminal should use $QIO (IO$_ACCESS) instead of the 
transparent $ASSIGN call to initiate logical links. 
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8.5.4.2 Completing the Logical Link Connection 

The target task completes the logical link by specifying the logi¬ 
cal name SYS$NET as the devnam argument for the $ASSIGN 
system service. For example: 

LOGNAM: .ASCID /SYS$NET/ 

NETCHAN: .BLKW 1 ; Channel number returned here 


$ASSIGN_S DEVNAM=LOGNAM.CHAN=NETCHAN 

Issue these calls in the target task to complete the logical link 
connection. The target task also specifies a channel to be used 
in subsequent system service calls. 

It is assumed that the remote node is a VAX/VMS system. 

If the remote node on which the target task runs is other 
than VAX/VMS, you should refer to the related DECnet 
documentation. 


8.5.4.3 Exchanging Messages 

After DECnet-VAX software establishes a logical link with 
the target task, either task can then send or receive messages. 
However, they must cooperate with each other: for each 
message sent with the $QIO (IO$_WRITEVBLK), the other task 
must issue a corresponding $QIO (IO$_READVBLK) to receive 
the message. 

You must ensure that the tasks allocate enough buffer space 
for receiving the messages; if they do not, a DATAOVERUN 
error will occur. You must also ensure that the end of the 
dialog can be determined. Finally, one of the two tasks must 
disconnect the logical link. To terminate a logical link properly, 
the receiver, and not the transmitter, of the final message 
should break the link. 


8.5.4.4 Terminating the Logical Link 

Use the $DASSGN system service call to deassign the channel 
and break off the logical link with the cooperating task. This 
call terminates all pending calls for sending and receiving 
messages, aborts the link immediately, and frees the channel 
associated with that logical link. 
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8.5.4.5 Status and Error Reporting 

When a system service completes execution, a status value 
is always returned. The SASSIGN, SDASSGN, and $QIO 
system services place the return status information in register 
0 (RO). For the SQIO system service, a successful status return 
indicates only that the request was queued successfully. All 
I/O completion status information is placed in the I/O status 
block (IOSB). For example, a $QIO system service read request 
to a task might be successful (status return is SS$_NORMAL) 
yet fail because the link was disconnected. (I/O status return 
is SS$_LINKABORT.) The return status codes shown in the 
following sections may be returned both in RO and in the IOSB, 

The VAX/VMS System Services Reference Manual and the Guide 
to Programming on VAX/VMS both describe the use of asyn¬ 
chronous system traps (ASTs), IOSBs, and event flags. 


8.5.5 Summary of System Service Calls for Transparent 

Operations 

The following sections describe the VAX/VMS system services 
you can use for transparent intertask communication. Each 
description covers the use of the call, its format, the arguments 
associated with the call, and the return status information. The 
VAX/VMS System Messages and Recovery Procedures Reference 
Manual lists the entire set of network system service error 
messages. 


8.5.5.1 SASSIGN 

The SASSIGN system service assigns a channel to refer to the 
logical link. You can then use the channel returned in the chan 
argument in any succeeding call to send or receive a message, 
or to deassign the channel and thereby terminate the logical 
link. 

Format 

SASSIGN devnam ,chan ,[acmode] 
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Arguments 

devnam Address of a quadword descriptor of a character string 
that identifies the remote task. The string will contain 
either of the following: 

• A task specification string if the call is by the source 
task. Both the string and its descriptor must be in 
read/write storage. 

• SYS$NET if the call is by the target task. (SYS$NET 
is a logical name.) 


chan Address of a word that will receive the assigned 

channel number. You use this channel number to send 
a message to a remote task, receive a message from a 
remote task, or to abort the logical link. 

acmode Access mode to be associated with this channel. The 
most privileged access mode used is the access mode 
of the caller. You can perform I/O operations on the 
channel only from equal or more privileged access 
modes. 


Return Status 

SS$_REMOTE 

SS$_CONNECFAIL 

SS$_DEVOFFLINE 

SS$_FILALRACC 

SS$_INSFMEM 

SS$_INVLOGIN 

S$_IVDEVNAM 

SS$_LINKEXIT 


The service completed successfully. (A 
logical link was established with the 
target task.) 

The connection to a network object timed 
out or failed. 

The physical link is shutting down. 

A logical link already exists on the chan¬ 
nel. 

There is not enough system dynamic 
memory to complete the request. 

The access control information was found 
to be invalid at the remote node. 

The task specifier has an invalid format or 
content. 

The network partner task was started, 
but exited before confirming the logical 
link (that is, $ASSIGN to SYS$NET). 
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SS$_NOLINKS 

SS$_NOPRIV 

SSS—NOSUCHNODE 

SS$_NOSUCHOBJ 

SS$_NOSUCHUSER 

SS$_PROT OCOL 

SS$_REJECT 

SS$_REMRSRC 


No logical links are available. The max¬ 
imum number of logical links as set for 
the NCP executor MAXIMUM LINKS 
parameter was exceeded. 

The issuing task does not have the 
required privilege to perform network 
operations or to confirm the specified 
logical link. 

The specified node is unknown. 

The network object number is unknown 
at the remote node; or for a TASK= 
connect, the named DCL command 
procedure file cannot be found at the 
remote node. 

The remote node could not recognize 
the login information supplied with the 
connection request. 

A network protocol error occurred, most 
likely because of a network software 
error. 

The network object rejected the connec¬ 
tion. 

The link could not be established because 
system resources at the remote node 
were insufficient. 


SS$_SHUT 

SS$_THIRDPARTY 

SS$_TOOMUCHDATA 

SS$_UNREACHABLE 


The local or remote node is no longer 
accepting connections. 

The logical link connection was termi¬ 
nated by a third party (for example, the 
system manager). 

The task specified too much optional or 
interrupt data. 

The remote node is currently unreachable. 


8.5.5.2 $QIO (Sending a Message to a Target Task) 

The $QIO system service with a function code of IO$_ 
WRITEVBLK sends a message to a target task. The $QIO 
call initiates an output operation by queuing a request to the 
channel associated with the logical link. Alternatively, you 
could use the $QIOW system service to perform the same 
operation but wait for I/O completion. 
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Format 

$QIO )[efn] ,chan ,func , [iosb] ,[astadr] ,[astprm] ,pl ,p2 

$Qiowr 

Arguments 

efn Number of the event flag to be set at request comple¬ 

tion. 

chan A word containing the channel number associated with 

the logical link. Use the same channel number returned 
previously in the $ASSIGN call. 

func IO$_WRITEVBLK 

iosb Address of a quadword I/O status block that is to 

receive the completion status. 

astadr Entry point address of an AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm AST parameter to be passed to the AST completion 
routine. 

pi Buffer address. 

p2 Buffer length in bytes. 


Return Status 

SS$_NORMAL 

SS$_ABORT 

SS$_CANCEL 
SS$_FILNOT ACC 

SS$_INSFMEM 

SS$_LINK ABORT 

SS$_LINKDISCON 

SS$_LINKEXIT 

SS$_PATHLOST 


The service completed successfully. 

The I/O request has been aborted by a 
$DASSGN or $CANCEL. 

The I/O on this channel has been cancelled. 

No logical link is associated with the 
channel. 

Enough memory to buffer the message 
could not be allocated. 

The network partner task aborted the 
logical link. 

The network partner task disconnected the 
logical link. 

The network partner task exited. 

The path to the network partner task node 
was lost. 
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SS$_PROTOCOL A network protocol error occurred. This 

is most likely due to a network software 
error. 

SS$_THIRDPARTY The logical link connection was terminated 
by a third party (for example, the system 
manager). 


8.5.5.3 $QIO (Receiving a Message from a Target Task) 

The $QIO system service with a function code of IO$_ 
READVBLK receives a message from a target task. The $QIO 
call initiates an input operation by queuing a request to the 
channel associated with the logical link. Alternatively, you 
could use the $QIOW system service to perform the same 
operation but wait for I/O completion. 

Format 

($QIO l[efn] .chan .func ,[iosb] ,[astadr] ,[astprm] ,pl ,p2 
|$QIOWj 

Arguments 

efn Number of the event flag to be set at request comple¬ 

tion. 

chan A word containing the channel number associated with 

the logical link. Use the same channel number returned 
previously in the SASSIGN call. 

func IO$_READVBLK 

iosb Address of a quadword I/O status block that is to 

receive the completion status. 

astadr Entry point address of an AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm AST parameter to be passed to the AST completion 
routine. 

pi Buffer address. 

p2 Buffer length in bytes. 
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Return Status 


SS$_NORMAL 

The service completed successfully. 

SS$_ABORT 

The I/O request has been aborted by a 
SDASSGN or SCANCEL. 

SS$_CANCEL 

The I/O on this channel has been cancelled. 

SS$_DAT AOVERUN 

More bytes were sent than could be 
received in the supplied buffer. 

SS$_FILNOT ACC 

No logical link is associated with the 
channel. 

SS$_INSFMEM 

Enough memory to buffer the message 
could not be allocated. 

SS$_LINKABORT 

The network partner task aborted the 
logical link. 

SS$_LINKDISCON 

The network partner task disconnected the 
logical link. 

SSS—LINKEXIT 

The network partner task exited. 

SSS—PATHLOST 

The path to the network partner task node 
was lost. 

SS$_PROT OCOL 

A network protocol error occurred. This 
is most likely due to a network software 


error. 

SS$_THIRDPARTY 

The logical link connection was terminated 
by a third party (for example, the system 
manager). 


8.5.5.4 $DASSGN (Terminating a Logical Link) 

The $DASSGN system service terminates all pending oper¬ 
ations to send and receive data, disconnects the logical link 
immediately, and frees the channel associated with that link. 
Either task can terminate the logical link by calling $DASSGN. 

Format 

$DASSGN chan 
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Arguments 

chan A word containing the channel number to the logical link 
you want disconnected. Use the same channel number 
returned previously in the $ASSIGN call. 

Return Status 

SS$_NORMAL The service completed successfully. 
SS$_IVCHAN An invalid channel number was specified. 

SS$_NOPRIV The specified channel was not assigned or was 
assigned from a more privileged access mode. 


8.6 Performing Nontransparent Task-To-Task Operations 

This section describes the system service calls and functions 
that you use for nontransparent task-to-task communication. In 
general, the principles of nontransparent task-to-task communi¬ 
cation are similar to those of transparent communication. 

If you wish to perform nontransparent communication opera¬ 
tions, you can write VAX MACRO programs using VAX/VMS 
system services designed specifically for DECnet-VAX. You 
can also write programs in one of the higher-level languages, 
provided that the language supports the DECnet-VAX services. 
These DECnet-VAX services are described in detail throughout 
this section. 

DECnet-VAX also provides additional services with extensions 
that allow you to use network-specific features for nontranspar¬ 
ent network operations such as the following: 

• Creating and using mailboxes for receiving messages, 
including network status notifications 

• Declaring a task as a network task, thus enabling it to 
process multiple inbound logical link connection requests 

• Sending connection requests, optionally with user data 

• Accepting or rejecting a connection request, optionally with 
user data 

• Communicating between a transparent and a nontransparent 
task 

• Sending or receiving an interrupt message 
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8 . 6.1 


Table 8-2 


• Aborting or synchronously disconnecting a logical link, 
optionally with user data 

The general concepts implicit in DECnet-VAX task-to-task 
communication are covered in Section 8.5. You should also be 
familiar with the material contained in the VAX/VMS System 
Routines Reference Volume and the VAX/VMS I/O Reference 
Volume. 


Using System Services for Nontransparent 
Operations 

Nontransparent task-to-task communication over the network 
uses a set of system service calls available under the VAX/VMS 
operating system. Table 8-2 summarizes these calls and their 
network-related functions. The $QIO calls are distinguished by 
function code. 


System Service Calls for Nontransparent 
Communication 


Call 

Function 

SASSIGN 

Assign an I/O 
channel 

SCANCEL 

Cancel I/O on a 
channel 

SCREMBX 

Create a mailbox 

SDASSGN 

Abort the logical 
link connection 
(deassigning an 
I/O channel) 

SGETDVI 

Get information 
on device or 
volume 

$QIO (IO$_ACCESS) 

Request a logical 
link connection 

$QIO (IO$_ACCESS) 

Accept a logical 
link connection 
request 
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Table 8-2 (Cont.) System Service Calls for Nontransparent 
Communication 


Call 


Function 


$QIO (IO$_ACCESS!IO$M_ABORT) 

$QIO (IO$_ACPCONTROL) 

$QIO (IO$_DEACCESS!IO$M_ABORT) 

$QIO (IO$_DEACCESS!IO$M_SYNCH) 

$QIO (IO$_READVBLK) 

$QIO (IO$_WRITEVBLK) 

$QIO (IO$_WRITEVBLK!IO$M_INTERRUPT) 

STRNLNM 


Reject a logical 
link connection 
request 

Assign a net¬ 
work name to a 
task eligible to 
accept multiple in¬ 
bound connection 
requests 

Abort the logical 
link connection 

Synchronously 
disconnect a 
logical link 

Receive a mes¬ 
sage 

Send a message 

Send an interrupt 
message 

Translate logical 
names 


8.6.1.1 Assigning a Channel to _NET: and Creating a Mailbox 

To prepare for nontransparent task-to-task communication, 
you need to assign a channel just as you would for transparent 
communication. In addition, you can create a mailbox to take 
advantage of optional network protocol features. 

You must assign a channel to a pseudodevice called __NET:; 
use the $ ASSIGN system service call for this purpose. This call 
normally contains a reference to a mailbox, thereby associating 
it with the channel assigned to _NET:. If you use a mailbox, 
you must create the mailbox before assigning a channel to 
_NET:. It is important to note that this use of the $ ASSIGN 
system service differs from its use for transparent commu¬ 
nication. Assigning a channel to _NET: does not transmit a 
logical link connection request to the remote node. Instead, the 
channel to _NET: provides a communication path to DECnet 
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A separate $QIO call (IO$_ACCESS function using the same 
channel) must be used to request a logical link to the remote 
task. 

To take advantage of optional network protocol features, 
you can create a mailbox to receive messages on behalf of 
logical link operations. For example, the mailbox receives a 
message indicating whether the cooperating task accepted or 
rejected a connection request issued by the source task. Use 
the $CREMBX system service to create a mailbox for these 
purposes. In the event that your application does not use 
mailbox messages, you need not create a mailbox. 

For convenience, the Run-Time Library routine LIB$ASN_ 
WTH_MBX can be used to create a temporary mailbox, assign 
a channel to it, and assign a channel to _NET:. This routine 
creates a unique mailbox in that multiple copies of the task 
using it will in effect use different mailboxes. If you were to 
create a mailbox with a logical name, all tasks would use the 
same mailbox and thereby interfere with each other's mailbox 
messages. For a complete description of this routine, see the 
VAX/VMS Run-Time Library Routines Reference Manual. 


8.6.1.2 Mailbox Message Format 

The mailbox receives information specific to nontransparent 
communication with a remote task. Figure 8-2 illustrates the 
general format of the mailbox message. 

Figure 8-2 Mailbox Message Format 
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Notes to Figure 8—2 


MSGTYPE 

UNIT 

COUNT NAME 


COUNT INFO 


Contains a code that identifies the message 
type. 

Contains the binary unit number of the device for 
which the message applies. 

Contains a counted ASCII string that gives the 
name of the device for which the message 
applies. The SASSIGN system service creates 
devices having names of "NET". 

Contains a counted ASCII string of information 
which depends on the message type. 


The VAX/VMS System Services Reference Manual summarizes 
the mailbox messages that pertain to nontransparent task-to- 
task communication. 


8.6.1.3 Requesting a Logical Link Connection 

Once you assign the I/O channel, you can request a logical link 
connection to the target task. Use the $QIO system service with 
a function code of IO$_ACCESS. You must identify the target 
task in the $QIO call. Use a network connect block (NCB) to 
specify the target task identification string. In addition, you 
can optionally send 1 to 16 bytes of data in the NCB. The 
NCB must be in read/write storage. The format of the NCB is 
discussed in Section 8.6.1.4. 

Once the source task issues the connection request, it can then 
issue a $QIO call with a function code of IO$_READVBLK to 
read its mailbox. Checking the contents of the mailbox is one 
way to determine whether the target task accepted or rejected 
the connection request. The mailbox will contain either MSG$_ 
CONFIRM or MSG$_REJECT, possibly with optional data in 
the mailbox buffer. 

If specified, the IOSB argument of the $QIO (IO$_ACCESS) call 
will also contain the result of the connection request operation. 
Section 8.6.2.2 provides a complete list of I/O status messages 
for this call. 

Note that you must read the mailbox to inspect any optional 
data sent from the target task upon accepting or rejecting the 
connection request. 
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8.6.1.4 Using the Network Connect Block 

The network connect block is a user-generated data structure 
that contains the information necessary to request a logical 
link connection or to accept or reject a logical link connection 
request. 

Example 8-1 is an example of an NCB you could use when 
issuing a connection request call. 

The significance of the information contained in the NCB block 
varies, depending on the type of call in which it is used. If the 
call is an outbound connection request with no optional data, 
items 2, 3, 4, and 5 of the block are not required. If the call is 
a connect accept operation and no optional data is sent, then 
items 4 and 5 are not required. Item 5 is meaningful only to 
the receiver of a connection request. 


Example 8-1 Network Connect Block Format 


1. With optional data (outbound connect): 

O © 

NCB: .ASCII 7TRNT0::"TASK=TEST2/? 

.WORD 0 © 

OPTDATA: 

.ASCIC /USERINFO/ 

.BLKB 17-<.-OPTDATA> O 
.ASCII /"/ 

0 

2. Without optional data (outbound connect): 

o 

NCB: .ASCII 7TRNT0: : "TASK=TEST2 ,, 7 


Item Function 


© A valid task specification string. For an inbound call with an 
NCB, the task name portion of the task specification string 
is a process ID if the remote node is a VAX/VMS system; if 
not, then the task name portion is a system-specific string 
that identifies an executable unit (for example, job or task). 
The task specification string must be a quoted string. Note 
that the final quotation mark of the task specification string 
follows the last item within the NCB. 
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© The slash character (/). 

© One word. This word must be 0 for a connection request 
operation. For a connect accept or reject operation, this 
word contains an internal DECnet link identifier. 

O Up to 16 bytes of optional data sent as a counted string. 
This string is stored in a fixed-length field that is 17 bytes 
long. DECnet-VAX software ignores unused bytes. 

© A destination descriptor. This descriptor indicates how the 
connection was issued and is meaningful only to the task or 
object to which the connection is made. This information is 
useful where one program serves many functions and needs 
to know how it was invoked. The maximum length for the 
destination descriptor is 19 bytes. The format is as follows: 

a If byte 0 contains 0, then byte 1 is the binary value of 
the object number. 

b If byte 0 contains 1, then byte 1 is the binary object 
number, and bytes 2 through 18 contain a counted task 
name. 

c If byte 0 contains 2, then byte 1 is the binary object 
number, bytes 2 through 5 contain a UIC, the first two 
bytes of which contain a binary group code and the 
second two bytes contain a binary user code, and bytes 6 
through 18 contain a counted task name. 


8.6.1.5 Completing the Logical Link 

A nontransparent target task completes the logical link connec¬ 
tion in one of several ways, depending upon whether the task 
can process multiple inbound connection requests or just a sin¬ 
gle request. Furthermore, a nontransparent target task has the 
option of accepting or explicitly rejecting a logical link request. 

Receiving Connection Requests 

This section describes what happens when you receive single 
and multiple connection requests. It is assumed that the remote 
node is VAX/VMS. If the remote node on which your target 
task runs is other than VAX/VMS, you should refer to the 
related DECnet documentation. 
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When a remote node receives a call requesting a logical link, the 
DECnet-VAX software constructs an NCB from the information 
contained in the call. At this point, one of two things occurs. 

If a process already running on the remote node has declared a 
network name or object number the same as the one identified 
in the NCB, then the software puts the NCB into that process's 
mailbox. If not, DECnet-VAX software either uses a compatible 
netserver process (if one exists) or creates a netserver process 
(if one does not already exist) to execute NETSERVER.COM, 
which in turn will run NETSERVER.EXE. 

SYS$NET is equated to the NCB, and LOGIN.COM (if it exists) 
is invoked, which in turn starts the taskname.COM command 
file. The name of this command file is determined as follows: 

• If the connection request identifies a numbered (nonzero) 
object, then the appropriate record is located in the config¬ 
uration database and the name of the file is found in this 
record. (The file is assumed to reside in SYSSSYSTEM.) 

• If the connection request identifies a named object with type 
0 (TASK), then the file name is assumed to be the name 

of the task connected to (with a file type of COM) and is 
assumed to reside in the default directory associated with 
the access control information. 

Once executing, the target task can then determine whether to 
accept or explicitly reject the connection request. You can pro¬ 
gram the target task to base this assessment on the information 
contained in the NCB. 

A nontransparent target task can accept only one connection 
request at a time, unless it declares itself as a network task. 

The target task may retrieve the connection information by 
translating the logical name SYS$NET using the $TRNLNM 
system service. Once the task retrieves the logical name, it may 
then decide whether to accept or explicitly reject the connection 
request. 

Note that you need to translate SYS$NET only if you require 
the following information: 

• The optional data in the network connect block 

• The identity of the connector 

• The descriptor by which the connection was made 
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A target task can accept multiple inbound connection requests 
only if it declares itself a known network task. To make this 
declaration, you must first use the $ASSIGN call to assign an 
I/O channel to _NET:. Then, use the $QIO system service with 

a function code of IO$_ACPCONTROL to assign a network 

name or object number to the task, making it eligible to process 
multiple inbound connection requests. This system service 
requires SYSNAM privilege. You must associate a mailbox with 
the channel if a name or number is to be declared. 

Programs that have declared names or object numbers should 
be programmed to terminate when their mailboxes receive a 
MSG$_NETSHUT message. Such programs must be restarted 
when the network comes back up. 

Once you declare the target task as an active network task, 
DECnet places all connection requests addressed to the task 
in the mailbox associated with the channel over which the 
ACP control function was issued. The target task retrieves 
connection requests from the mailbox by issuing the $QIO 
system service call with a function code of IO$_READVBLK. 
Note that the first message in the mailbox is the NCB from 
the original connection request that put the task into a state of 
execution. Once the task declares a network name or object 
number, subsequent inbound connection requests are not 
checked for their access control information. (However, if the 
network task is started separately from a DECnet operation, 
access control is never checked.) 

Note that you can start programs that declare names or object 
numbers apart from the first inbound connection (that is, by a 
RUN command). 

Accepting Or Rejecting A Connection Request 

The target task can either accept or explicitly reject a connection 
request. To accept a connection request, thus completing the 
logical link connection, use the $QIO system service with 
a function code of IO$__ACCESS. To reject the connection 
request, use the $QIO system service with the function code 

IO$_ACCESS!IO$M_ABORT. When it either accepts or rejects 

the connection request, the target task can also send 1 to 16 
bytes of optional data within a modified NCB back to the 
source task. 
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Exchanging Data Messages and Receiving Interrupt 
Messages 

The exchange of data messages between the two cooperating 
tasks is performed in the same way for both nontransparent 
and transparent communication. (Refer to Section 8.5.5 for 
information on using the system service calls $QIO (IO$_ 
WRITEVBLK) and $QIO (IO$_READVBLK) to send and receive 
messages.) 

The receiving of information applies only to nontransparent 
communication. Either task can send a 1- to 16-byte interrupt 
message. You can use this method to send a message to a 
target task outside the normal flow of data messages. DECnet- 
VAX places the received interrupt message in the target task's 
mailbox. Use the $QIO system service with a function code 
of IO$_WRITEVBLK!IO$M_INTERRUPT to send the interrupt 
message. To notify the target task that an interrupt message 
has been placed in its mailbox, the task should issue a $QIO 
system service call with a function code of IO$_READVBLK 
to the mailbox. Specifying an AST routine in the $QIO system 
service call will cause the routine to be executed on receiving 
the interrupt message. (AST routines are described in the 
VAX/VMS System Services Reference Manual. 


8.6.1.6 Disconnecting or Aborting the Logical Link 

A nontransparent task can terminate communication with a 
remote task either by disconnecting the link (synchronous dis¬ 
connect or disconnect abort) or by deassigning the channel. In 
the first instance, you can issue a new connection request on the 
same channel because you do not deassign it. If you specifically 
use the IO$_DEACCESS, as opposed to the $DASSGN method 
of terminating a link, you can send an optional message of 1 to 
16 bytes of data with the $QIO call. 

To disconnect a logical link synchronously, issue the $QIO 
system service with a function code of IO$_DEACCESS!IO$M_ 
SYNCH. The channel is then free for subsequent communica¬ 
tion with either the same or a different remote task. 

A synchronous disconnect may be useful for master/slave 
communication, in which one task always sends data and 
its partner task always receives data. If the receiving task is 
notified of a synchronous disconnection, then all the data that 
was sent has been received. (The sending task, on the other 
hand, is not guaranteed that its partner received the data.) 
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Because this notification is the only guarantee provided by this 
operation, using this operation is discouraged in favor of a 
user-defined protocol to ensure completion of communication. 
In general, the receiver of the final message should break the 
logical link. 

To abort the logical link, issue the $QIO system service with a 
function code of IO$_DEACCESS!IO$M_ABORT. This form of 
disconnection indicates to the receiver that not all messages sent 
have necessarily been received. To ensure that all transmitted 
messages have been received, the task itself must terminate 
I/O operations on the link before instituting the DEACCESS 
function because this function never completes before all 
pending I/O operations complete. To do so, first issue the 
SCANCEL system service to terminate I/O operations over the 
link; then, issue the $QIO system service to terminate the link. 

Note that after either a synchronous disconnect or a disconnect 
abort, you can issue a new connection request if you did not 
deassign the I/O channel. 

If you issue the $CANCEL system service to a channel over 
which a network name or object has been declared, the declara¬ 
tion will be removed from the network database. 


8.6.1.7 Terminating The Logical Link 

You can issue the $DASSGN system service call to deassign 
the channel and terminate the logical link immediately. You 
issue the call only after all communication between the tasks 
is complete. The call releases the I/O channel, disassociates 
the mailbox from the channel, and terminates the logical link 
immediately. This operation is equivalent to using $ CANCEL 
followed by $QIO IO$_DEACCESS!IO$M_ABORT. 

The same status and error reporting considerations apply to 
nontransparent as to transparent task-to-task communication. 
Refer to Section 8.5.4.5 for information on status and error 
reporting. 
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8.6.2 System Service Calls for Nontransparent Operations 

The following sections describe the VAX/VMS system services 
you can use for nontransparent intertask communication over 
the network. Each description covers the use of the call, 
its format, the arguments associated with the call, and the 
return status information. The VAX/VMS System Messages and 
Recovery Procedures Reference Manual lists the entire set of 
network system service error messages. 

The following system services are not described in detail below, 
because their use does not change in a networking context. For 
a description of these system services, see the VAX/VMS System 
Services Reference Manual. 

• $CANCEL (Cancel I/O on Channel) 

• $CREMBX (Create Mailbox and Assign Channel) 

• $GETDVI (Get Device/Volume Information) 

Note that $GETDVI performs the same function as the Get I/O 
Channel Information ($GETCHN) system service. However, 
DIGITAL recommends that you use the $GETDVI system 
service. 


8.6.2.1 $ASSIGN (I/O Channel Assignment) 

The $ASSIGN system service assigns a channel to refer to 
a logical link. You use this channel in all $QIO calls that 
communicate with a remote task. In addition, you can use the 
$ASSIGN system service call to associate a mailbox with the 
channel. 

Format 

SASSIGN devnam ,chan .[acmode] ,[mbxnam] 
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Arguments 

devnam Address of a quadword descriptor of a character string 
containing the string _NET: or a logical name for _NET:. 

chan Address of a word that will receive the assigned 

channel number. 

acmode Access mode to be associated with this channel. The 
most privileged access mode used is the access mode 
of the caller. You can perform I/O operations on the 
channel only from equal or more privileged access 
modes. 

mbxnam Address of a character string descriptor for the physical 
name of the mailbox to be associated with the channel. 
This mailbox remains associated with the channel until 
the channel is deassigned (SDASSGN). 


Return Status 


SS$_NORMAL 

SS$_INSFMEM 

SS$_NOPRIV 

SS$_NOSUCHDEV 


The service completed successfully. 

There is not enough system dynamic mem¬ 
ory to complete the request. 

The issuing task does not have the required 
privileges to create the channel. 

The network device driver is not loaded (for 
example, the DECnet-VAX software is not 
running currently on the local node). 


8.6.2.2 $QIO (Requesting A Logical Link Connection) 

The $QIO system service with a function code of IO$_ACCESS 
requests a logical link connection to a target task. You can send 
1 to 16 bytes of optional data to the target task at the same time 
that you issue the $QIO system service. 

Format 

$QIO [efn] .chan ,func , [iosb] ,[astadr] , [astprm] , [pi] ,p2 
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Arguments 

efn Number of the event flag to be set at request comple¬ 

tion. 

chan Address of a word containing the channel number 

associated with the logical link. Use the same channel 
number returned previously in the $ASSIGN call. 

func IO$_ACCESS 

iosb Address of a quadword I/O status block that is to 

receive the completion status. 

astadr Entry point address of an AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm AST parameter to be passed to the AST completion 
routine. 

pi Not used (omit the argument). 

p2 address of a quadword descriptor of the NCB (see 

Section 8.6.1.4). Both the descriptor and the NCB must 
be in read/write storage. 


Return Status 

SS$_NORMAL 

SS$_CONNECFAIL 

SS$_DEVOFFLINE 

SS$_FILALRACC 

SS$_INSFMEM 

SS$_INVLOGIN 

SS$_IVDEVNAM 

SS$_LINKEXIT 

SS$_NOLINKS 


The service completed successfully. 

The connection to a network object timed 
out or failed. 

The physical link is shutting down. 

A logical link is already accessed on the 
channel (that is, a previous connection is 
active on the channel). 

There is not enough system dynamic 
memory to complete the request. 

The access control information was found 
to be invalid at the remote node. 

The NCB has an invalid format or content. 

The network partner task was started, 
but exited before confirming the logical 
link (that is, $ASSIGN to SYS$NET). 

No logical links are available. The max¬ 
imum number of logical links as set for 
the executor MAXIMUM LINKS parameter 
was exceeded. 
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SS$_NOPRIV 

SS$_NOSUCHNODE 

SS$_NOSUCHOBJ 

SS$_NOSUCHUSER 

SS$_PROT OCOL 

SSS—REJECT 


The issuing task does not have the 
required privileges to create a logical link 
to the designated target. 

The specified node is unknown. 

The network object number is unknown 
at the remote node; or for a TASK= 
connect, the named DCL command 
procedure file cannot be found at the 
remote node. 

The remote node could not recognize 
the login information supplied with the 
connection request. 

A network protocol error occurred. This 
error is most likely due to a network 
software error. 

The network object rejected the connec¬ 
tion. 


SS$_REMRSRC The link could not be established because 

system resources at the remote node 
were insufficient. 


SS$_SHUT 
SS$_THIRDPARTY 
SS$_TOOMUCHDAT A 
SS$_UNREACHABLE 


The local or remote node is no longer 
accepting connections. 

The logical link was terminated by a third 
party (for example, the system manager). 

The task specified too much optional or 
interrupt data. 

The remote node is currently unreachable. 


8.6.2.3 $QIO (Accepting A Logical Link Connection Request) 

The $QIO system service with a function code of IO$_ACCESS 
accepts a logical link connection request from a source task. 
You can send 1 to 16 bytes of optional data to the source task 
at the same time that you issue the $QIO system service. 

Format 

$QIO [efn] .chan .func .[iosb] ,[astadr] ,[astprm] ,[pi] ,p2 
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Arguments 

efn Number of the event flag to be set at request comple¬ 

tion. 

chan Address of a word containing the channel number 

associated with the logical link. Use the same channel 
number returned previously in the $ASSIGN call. 

func IO$_ACCESS 

iosb Address of a quadword I/O status block that is to 

receive the completion status. 

astadr Entry point address of an AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm AST parameter to be passed to the AST completion 
routine. 

pi Not used (omit the argument). 

p2 Address of a quadword descriptor of the NCB (see 

Section 8.6.1.4). Both the descriptor and the NCB must 
be in read/write storage. 


Return Status 


SS$_NORMAL 

The service completed successfully. 

SS$_DEV ALLOC 

The process cannot access the logical link 
specified in the NCB because that link is 
intended for another process. 

SSS—EXQUOT A 

The process does not have sufficient 
quota to complete the request. 

SS$_INSFMEM 

There is not enough system dynamic 
memory to complete the request. 

SS$_IVDEVNAM 

The NCB has an invalid format or content. 

SS$_LINK ABORT 

The network partner task aborted the 
logical link. 

SS$_LINKDISCON 

The network partner task disconnected 
the logical link. 

SS$_LINKEXIT 

The network partner task exited. 

SS$_NOSUCHNODE 

The specified node is unknown. 

SS$_PATHLOST 

The path to the network partner task 
node was lost. 
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SS$_PROT OCOL 

SS$_THIRDPARTY 

SS$_TIMEOUT 

SS$_UNREACHABLE 


A network protocol error occurred. This 
error is most likely due to a network 
software error. 

The logical link connection was termi¬ 
nated by a third party (for example, the 
system manager). 

The connection request did not complete 
within the required time. 

The remote node is currently unreachable. 


8.6.2.4 $QIO (Rejecting A Logical Link Connection Request) 

The $QIO system service with a function code of IO$_ 

ACCESS!IO$M_ABORT rejects a logical link connection re¬ 
quest. You can send 1 to 16 bytes of optional data to the target 

task at the same time that you issue the $QIO system service. 

Format 

$QIO [efn] .chan ,func ,[iosb] ,[astadr] ,[astprm] ,[pi] ,p2 

Arguments 

efn Number of the event flag to be set at request 

completion. 

chan Address of a word containing the channel number 

associated with the logical link. Use the same channel 
number returned previously in the $ASSIGN call. 

func IO$_ACCESS!IO$M_ABORT 

iosb Address of a quadword I/O status block that is to 

receive the completion status. 

astadr Entry point address of an AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 
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astprm AST parameter to be passed to the AST completion 
routine. 

pi Not used (omit the argument). 

p2 Address of a quadword descriptor of the NCB (see 

Section 8.6.1.4). Both the descriptor and the NCB must 
be in read/write storage. 


Return Status 


SS$_NORMAL 

The service completed successfully. 

SS$_DEV ALLOC 

The process cannot access the logical link 
specified in the NCB because that link is 
intended for another process. 

SS$_EXQUOT A 

The process does not have sufficient 
quota to complete the request. 

SS$_IVDEVNAM 

The NCB has an invalid format or content. 

SS$_LINK ABORT 

The network partner task aborted the 
logical link. 

SS$_LINKDISCON 

The network partner task disconnected 
the logical link. 

SS$_LINKEXIT 

The network partner task exited. 

SS$_NOSUCHNODE 

The specified node is unknown. 

SS$_TIMEOUT 

The connection request did not complete 
within the required time. 

SS$_PATHLOST 

The path to the network partner task 
node was lost. 

SS$_PROT OCOL 

A network protocol error occurred. This 
error is most likely due to a network 
software error. 

SS$_THIRDPARTY 

The logical link connection was termi¬ 
nated by a third party (for example, the 
system manager). 

SS$_UNREACHABLE 

The remote node is currently unreachable. 


8.6.2.5 $QIO (Sending A Message To A Target Task) 

The $QIO system service with a function code of IO$_ 
WRITEVBLK sends a message to a target task. Refer to Sec¬ 
tion 8.6.2.7 for the format of this call, its arguments, and 
possible return status codes. 
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8.6.2.6 $QIO (Receiving A Message From A Target Task) 

The $QIO system service with a function code of IO$_ 
READVBLK receives a message from a target task. Refer to 
Section 8.6.2.7 for the format of this call, its arguments, and 
possible return status codes. 


8.6.2.7 


$QIO (Sending An Interrupt Message To A Target Task) 

The $QIO system service with a function code of IO$_ 
WRITEVBLK!IO$M_INTERRUPT sends a 1- to 16-byte in¬ 
terrupt message to a target task. If the remote node is a 
VAX/VMS system, the message is placed in the mailbox 
associated with the target task. 

Format 

$QIO [efn] ,chan ,func , [iosb] ,[astadr] ,[astprm] ,pl ,p2 


Arguments 

efn Number of the event flag to be set at event completion. 

chan Address of a word containing the channel number 

associated with the logical link. Use the same channel 
number returned previously in the SASSIGN call. 

func IO$_WRITEVBLK!IO$M_INTERRUPT 

iosb Address of a quadword I/O status block that will 

receive the completion status. 

astadr Entry point address of the AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm The AST parameter to be passed to the AST comple¬ 
tion routine. 

pi Buffer address. 

p2 Buffer length (1 to 16 bytes). 


Return Status 

SS$_NORMAL 

SS$_ABORT 

SS$_FILNOT ACC 


The service completed successfully. 

The I/O request has been aborted by a 
SDASSGN or $CANCEL call. 

No logical link is associated with the 
channel. 
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8.62.8 





SS$_INSFMEM Enough memory to buffer the message 

could not be allocated. 


SS$_LINKABORT 

SS$_LINKDISCON 

SS$_LINKEXIT 

SS$_NOSOLICIT 

SS$_T OOMUCHD AT A 


The network partner task aborted the 
logical link. 

The network partner task disconnected 
the logical link. 

The network partner task exited. 

DECnet could not accept an interrupt 
message at this time. 

The task specified too much interrupt 
data. 


SS$_PATHLOST The path to the network partner task 

node was lost. 


SS$_PROTOCOL A network protocol error occurred. This 

error is most likely due to a network 
software error. 


SS$_THIRDPARTY The logical link connection was termi¬ 
nated by a third party (for example, the 
system manager). 


$QIO (Synchronously Disconnecting A Logical Link) 

The $QIO system service with a function code of 10$_ 
DEACCESS!IO$M_SYNCH synchronously disconnects the 
logical link. All pending messages are transmitted to the 
remote node before the link is disconnected. 

You can send 1 to 16 bytes of optional data to the task from 
which you are disconnecting at the same time you issue this 
$QIO system service. 

Format 

$QIO [efn] .chan ,func , [iosb] ,[astadr] ,[astprm] , [pi] , [p2] 


Arguments 

efn Number of the event flag to be set at event completion. 

chan Address of a word containing the channel number 

associated with the logical link. Use the same channel 
number returned previously in the $ASSIGN call. 

func IO$_DE ACCESS! IO$M_SYNCH 
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8.6.2.9 


iosb Address of a quadword I/O status block that will 

receive the completion status. 

astadr Entry point address of the AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm The AST parameter to be passed to the AST comple¬ 
tion routine. 

pi Not used (omit the argument). 

p2 Address of a descriptor of a counted ASCII string of 

optional user data. Both the string and its descriptor 
must be in read/write storage. 

Return Status 

SS$_NORMAL The service completed successfully. 

SS$_FILNOTACC No logical link is associated with the channel. 


$QIO (Aborting A Logical Link) 

The $QIO system service with a function code of IO$_ 
DEACCESS!IO$_ABORT terminates the logical link. Note, 
however, that the DEACCESS function completes only after 
all pending I/O operations complete, even though you specify 
IO$_ABORT. First, issue the $CANCEL system service call to 
cancel I/O operations on the logical link and then issue this call 
to terminate the logical link. 

You can send 1 to 16 bytes of optional data to the task from 
which you are disconnecting at the same time that you issue 
this $QIO system service call. 

Format 

$QIO [efn] , chan .func , [iosb] .[astadr] .[astprm] . [pi] . [p2] 

Arguments 

efn Number of the event flag to be set at event completion. 

chan Address of a word containing the channel number 

associated with the logical link. Use the same channel 
number returned previously in the $ASSIGN call. 

func IO$_DE ACCESS! IO$M_ABORT 
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8.6.2.10 


iosb Address of a quadword I/O status block that will 

receive the completion status. 

astadr Entry point address of the AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm The AST parameter to be passed to the AST comple¬ 
tion routine. 

pi Not used (omit the argument). 

p2 Address of a quadword descriptor of a counted string 

of optional user data. Both the string and its descriptor 
must be in read/write storage. 

Return Status 

SS$_NORMAL The service completed successfully. 

SS$_FILNOTACC No logical link is associated with the channel. 


$QIO (Declaring A Network Name Or Object Number) 

The $QIO system service with a function code of IO$_ 
ACPCONTROL assigns a network name or object number 
to the task, thereby making it eligible to process multiple in¬ 
bound connection requests. You must associate a mailbox with 
the I/O channel. All inbound connection requests are placed 
in the mailbox associated with the channel over which this I/O 
function is issued. The SYSNAM privilege is required to declare 
a name or object number. 

MACRO programmers should be aware that whenever a logical 
link is established, its device unit number (for example, 18 from 
_NET18:) should be obtained by using the $GETDVI system 
service, because unit numbers and not channel numbers appear 
in mailbox messages. Use this system service call where a 
single mailbox is being used for many logical links. The unit 
number could be used as a key into a database that keeps track 
of multiple links. 

Format 

$QI0 [efn] ,chan ,func , [iosb] .[astadr] .[astprm] ,pl ,p2 
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Arguments 

efn Number of the event flag to be set at event completion. 

chan A word containing the channel number associated with 

the logical link. Use the same channel number assigned 
previously in the $ASSIGN call. 

func IO$_ACPCONTROL 

iosb Address of a quadword I/O status block that will 

receive the completion status. 

astadr Entry point address of the AST routine that executes 
when the I/O operation completes. If specified, the 
AST routine executes at the access mode from which 
the $QIO service was requested. 

astprm The AST parameter to be passed to the AST comple¬ 
tion routine. 

pi Address of a quadword descriptor of a 5-byte block 

consisting of a function type (one byte) and a longword 
parameter. The function type is a symbol defined by 
the $NFBDEF macro in SYS$LIBRARY:LIB.MLB. The 
format of the 5-byte block for declaring a name is 

.BYTE NFB$C_DECLNAME 
.LONG 0 

The format of the 5-byte block for declaring an object 
number is 

.BYTE NFB$C_DECLOBJ 
.LONG object-number 


The object number is a number reserved for customer 
use in the range of 128 to 255. This 5-byte buffer and 
its descriptor should be in read/write storage. 
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p2 Address of a quadword descriptor of the network 

name (maximum of 12 characters). This argument is 
ignored for the DECLOBJ function. Both the name and 
its descriptor must be in read/write storage. 


Return Status 

SS$_NORMAL 

SS$_BADPARAM 

SS$_ILLCNTRFUNC 

SSS—NOMBX 

SS$_NOPRIV 


The service completed successfully. 

One of the QIO parameters has an invalid 
value. 

The control function is invalid. 

A name or object number is being 
declared using a channel without an 
associated mailbox. 

The issuing process does not have the 
SYSNAM privilege. 


8.6.2.11 $DASSGN (Terminating A Logical Link) 

The $DASSGN system service terminates all pending opera¬ 
tions to send and receive data, aborts the logical link immedi¬ 
ately, and frees the channel associated with that link. Refer to 
Section 8.5.5.4 for the format of this call, its arguments, and 
possible return status codes. 


8.7 Designing Tasks 

This section contains a command procedure and three user 
program examples designed to perform task-to-task communi¬ 
cations over the network. 

The command procedure and the first two user program exam¬ 
ples illustrate transparent operations. The third user program 
example illustrates a nontransparent operation. 


8-55 






Performing Network User Operations 


8.7.1 


DCL Command Procedure for Task-to-Task 
Communication 

As described in Section 8.5, you can write command procedures 
in DCL to execute transparent task-to-task operations. The 
command procedure below, called SHOWBQ.COM, can be used 
to perform such an operation. You can use SHOWBQ.COM for 
task-to-task communication by entering a task-spec-string in a 
TYPE command. For example: 

$ TYPE TRNTO"BROWN JUNE"::"TASK=SHOWBQ" 

In this command procedure, SYS$OUTPUT is equated to 
SYS$NET in user mode to allow the SHOW QUEUE image to 
communicate over the logical link by opening SYS$OUTPUT. 
When the SHOW QUEUE image exits, the temporary definition 
of SYS$OUTPUT is deleted. In other words, only one DCL 
image can use the logical link as the communication path to the 
requestor at the other node. 

SHOWBQ.COM 

$ ! 

$ ! This command procedure returns status information about 

$ ! jobs entered in batch queues on the system where it 

$ ! executes. It may be run interactively as a command 

$ ! procedure, submitted as a local or remote batch job, or 

$ ! invoked as a "remote task" to display information about 

$ ! another system. For example: 

$ ! 

$ ! $ QSHOWBQ 

$ ! $ SUBMIT SHOWBQ 

$ ! $ SUBMIT/REMOTE node::SHOWBQ 

$ ! $ TYPE node::"TASK=SHOWBQ" 

$ ! 

$ IF F$MODE() .EQS. "NETWORK" THEN GOTO NET 
$ SHOW QUEUE/BATCH/BRIEF/ALL 
$ EXIT 
$NET: 

$ DEFINE/USER SYS$OUTPUT SYS$NET 
$ SHOW QUEUE/BATCH/BRIEF/ALL 
$ PURGE/KEEP=1 SYS$LOGIN:SHOWBQ.LOG 
$ EXIT 
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8.7.2 


Fortran Program for Task-to-Task Communication 

Example 8-2 is a simple example of VAX FORTRAN transpar¬ 
ent communication. In the FORTRAN source task that initiates 
the logical link request, you use a standard open statement to 
specify the remote task to which you want to connect. In turn, 
the remote task issues an open statement to complete the logical 
link connection. A coordinated set of read and write operations 
enable the exchange of information over the link. To terminate 
the connection, the source task executes a close statement to 
break the logical link. When the remote task receives this close 
statement, it issues a close statement, which completes the link 
termination process. The remainder of this section discusses the 
statements that you would use to develop such an application. 
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PROGRAM TEST3.FOR 
C 

C This program prompts the user for the part number of an item 

C in inventory and responds with the number of units in stock. 

C The information is obtained by communicating with a program 

C (TEST4) on another node that has access to the inventory data. 

C 

C Before running this program, the logical name TASK must be 

C defined to refer to the target program. For example: 

C 

C $ DEFINE TASK "TRNTO::""TASK=TEST4""" 

C $ RUN TEST3 

C 

CHARACTER PARTN0*5 
INTEGER PARTCOUNT 
C 

100 FORMAT (/,'$Enter part number: ') 

200 FORMAT (A) 

300 FORMAT (14) 

400 FORMAT ('OInventory for part number ',A,' is: ',14) 

C 

C Establish a logical link with the target task. 

C 

O OPEN (UNIT=1,NAME= ' TASK ' ,ACCESS= • SEQUENTIAL ' , 

1 F0RM='FORMATTED',CARRIAGECONTROL='NONE',TYPE='NEW') 

C 

C Prompt the user for a part number, send it to the target task, 

C read reply of quantity on hand, and finally display the answer 

C for the user. Repeat the cycle until the user enters 'EXIT' for 

C a part number. 

C 

10 TYPE 100 

ACCEPT 200, PARTNO 
IF (PARTNO .EQ. 'EXIT') GOTO 20 
O WRITE (1,200) PARTNO 
READ (1,300) PARTCOUNT 
TYPE 400, PARTNO, PARTCOUNT 
GOTO 10 
C 

C Disconnect the logical link. 

C 

20 © CLOSE (UNIT=1) 

END 
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$ ! TEST4.COM 

$ ! 

$ ! This command procedure executes the program TEST4 after 

$ ! being started by a task-to-task connection request issued 

$ ! by TEST3. 

$ ! 

© $ RUN SYS$LOGIN:TEST4.EXE 

$ ! 

$ ! Purge old log files generated by this command procedure. 

$ ! 

$ PURGE/KEEP=2 SYS$L0GIN:TEST4.LOG 
$ EXIT 

PROGRAM TEST4.FOR 
C 

C Test4 is the target program that communicates with TEST3. 

C For each part number received from the source task, the 

C number of units in stock is determined, and this value is 

C returned. 

C 

C To complete the logical link with its initiator, this program 

C uses the logical name SYS$NET as the file specification in an 

C open statement. 

C 

CHARACTER PARTN0*5 
INTEGER PARTCOUNT 
C 

100 FORMAT (A) 

200 FORMAT (14) 

C 

C Complete the logical link connection. 

C 

© OPEN (UNIT=1,NAME='SYS$NET',ACCESS='SEQUENTIAL', 

1 F0RM='FORMATTED',CARRIAGECONTROL='NONE',TYPE='OLD') 

C 

C Process requests until end-of-file is reached. (This is the 

C error condition returned when the source task breaks the 

C logical link connection.) 

C 

10 © READ (1,100,END=20) PARTNO 

C 

C Perform appropriate processing to obtain the part count value 

C and transmit this back to the source task. 

C 

CALL INSTOCK (PARTNO,PARTCOUNT) 

© WRITE (1,200) PARTCOUNT 
GOTO 10 

C 

C Disconnect the logical link. 

C 

20 © CLOSE (UNIT=1) 

END 
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Notes on Example 8—2 

O The source task, TEST3, requests a logical link connection to 
the target task, TEST4. 

© When the remote node receives a connection request, the 
command procedure TEST4.COM is executed. This com¬ 
mand procedure must reside in the default directory associ¬ 
ated with the account being accessed. TEST4.COM contains 
a RUN statement that causes the program TEST4.EXE to be 
executed. 

© TEST4 completes the logical link connection through 
SYS$NET. Note that the unit numbers in the source and 
target programs need not be the same. 

© TEST3 and TEST4 send and receive data messages. 

© TEST3 disconnects the logical link and thereby terminates 
the communication process. 

Because DECnet-VAX translates system-dependent language 
calls into the same set of messages that permit task-to-task 
communication, any task programmed in VAX MACRO or 
one of the higher-level languages can communicate with a 
remote task programmed in the same or a different language. 
More specifically, for communication between tasks that run 
on VAX/VMS nodes, the language in which you access the 
network has no effect on the communication process. The VAX 
FORTRAN source task in Example 8-2 could just as easily 
communicate with a MACRO task on node TRNTO. 
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8.7.3 


MACRO Program for Transparent Task-to-Task 
Communication 

Example 8-3 illustrates the use of system service calls for 
transparent communication. TRANA is a MACRO source task 
on the local node that communicates with a target task, TRANB, 
on node TRNTO. The source task sends a connection request 
to the remote node whereupon the target task is started by the 
command file TRANB.COM. Once the logical link connection is 
made, the source task sends a message to the target task, which 
in turn responds with a message and then waits for additional 
message traffic. The source task drives the communication 
process. Once the source task receives a response from the 
target task, it disconnects the link and exits, which causes the 
target task to exit also, thereby terminating the communication 
process. 
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Example 8-3 Transparent Communication Using System Services 


.TITLE TRANA - SOURCE TASK USING TRANSPARENT I/O 
.IDENT /VI.0/ 

.SBTTL WRITABLE.DATA 

.PSECT TRANA$DATA SHR,NOEXE,RD,WRT,BYTE 


NETCHAN:.BLKW 1 
IOSBUF: .BLKQ 1 

TARGET: .ASCID /TRNTO"MALIK KARL"::"TASK=TRANB"/ 


Network channel 
I/O status block 
Task-spec (and descriptor) 


SENDMSG:.ASCII /SEND THIS STRING TO TRANB/ 
SENDMSG_SIZ=.-SENDMSG 
RECVMSG:.BLKB 512 
RECVMSG_SIZ=.-RECVMSG 


Output buffer 
Output buffer size 
Input buffer 
Input buffer size 


.SBTTL MAIN 

.PSECT TRANA$CODE NOSHR.EXE,RD,NOWRT,BYTE 

.ENTRY START,~M<> ;Entry point from exec 


Request a logical link to the target 

$ASSIGN_S - 

DEVNAM=W~TARGET,- 
CHAN=VT NETCHAN 
BLBC RO,EXIT 

Send a message to the target task. 

$QIOW_S - 

EFN=#1,- 

CHAN=W~NETCHAN,- 
FUNC=S~#IO$_WRITEVBLK,- 
IOSB=W~IOSBUF,- 
P1=VT SENDMSG.- 
P2=S~#SENDMSG_SIZ 
BLBC RO,EXIT 

MOVZWL W~IOSBUF.RO 

BLBC RO,EXIT 

Receive a message from the target task 

$QI0W_S - 

EFN=#1.- 

CHAN=W~NETCHAN,- 
FUNC=S~#IO$_READVBLK,- 
I0SB=W~IOSBUF,- 
P1=W~RECVMSG,- 
P2=#RECVMSG_SIZ 
BLBC RO.EXIT 

MOVZWL IOSBUF.RO 

BLBC RO.EXIT 


;k and assign an I/O channel. 

Assign a channel to target task 
Address of device name descriptor 
Address to receive channel number 
Branch on failure 


Issue transmit request 
Use local event flag number 1 
Use assigned channel 
Write virtual block 
Address of I/O status block 
Address of output buffer 
Size of output buffer 
Branch on failure 
Get completion status 
Branch on failure 


Issue receive request 

Use local event flag number 1 

Use assigned channel 

Read virtual block 

Address of I/O status block 

Address of input buffer 

Size of input buffer 

Branch on failure 

Get completion status 

Branch on failure 
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Services 


Abort the logical link. 

$DASSGN_S - 

CHAN=VTNETCHAN 


Deassign the channel 

Address of word containing channel number 


; Exit with status (in RO). 

EXIT: $EXIT_S RO ; Exit with status to be displayed 

; on error condition 

.END START ; Image transfer address 

.TITLE TRANB - TARGET TASK USING TRANSPARENT I/O 
.IDENT /VI.0/ 

.SBTTL WRITABLE.DATA 

.PSECT TRANBSDATA SHR,NOEXE,RD,WRT,BYTE 


NETCHAN:.BLKW 1 
IOSBUF: .BLKQ 1 
RECVMSG:.BLKB 512 
RECVMSG_SIZ=.-RECVMSG 
LOGNAM: .ASCID /SYS$NET/ 

SENDMSG:.ASCII /REPLY TO TRANA/ 
SENDMSG_SIZ=.-SENDMSG 


Network channel 

I/O status block 

Input buffer 

Input buffer size 

Logical name and descriptor 

Output buffer 

Output buffer size 


.SBTTL MAINLINE 

.PSECT TRANBSCODE NOSHR,EXE,RD,NOWRT,BYTE 

.ENTRY START,~M<> ;Entry point from exec 


Complete the logical link connection (that TRANA requested). 


$ASSIGN_S - 

DEVNAM=VT LOGNAM,- 
CHAN=W~NETCHAN 
BLBC RO,EXIT 

LOOP: 


Assign channel to SYS$NET 
Descriptor of SYS$NET 
Store channel number 
Branch on failure 


Receive message from source task. 

$QI0W_S - 

EFN=#1,- 

CHAN=W ~ NET CHAN,- 
FUNC=S~#IO$_READVBLK,- 
I0SB=W~IOSBUF,- 
P1=W~RECVMSG,- 
P2=#RECVMSG_SIZ 
BLBC RO,EXIT 

MOVZWL W~I0SBUF.ro 

CMPW S~#SS$_AB0RT,RO 

BEQL DONE 

BLBC RO.EXIT 


Issue receive request 

Use local event flag number 1 

Use assigned channel 

Read virtual block 

Address of I/O status block 

Address of input buffer 

Size of input buffer 

Branch on failure 

Get completion status 

Was logical link aborted? 

Branch if yes 

Branch on failure 
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Example 8-3 (Cont.) Transparent Communication Using System 

Services 

; Send message to source task. 

$QIOW_S - 

Issue transmit request 

EFN=#1,- 

Use local event flag number 1 

CHAN=VT NETCHAN.- 

Use assigned channel 

FUNC=S~#IO$_WRITEVBLK,- 

Write virtual block 

IOSB=W~IOSBUF,- 

Address of I/O status block 

P1=VTSENDMSG,- 

Address of output buffer 

P2=S ~#SENDMSG_SIZ 

Size of output buffer 

BLBC RO,EXIT 

Branch on failure 

MOVZWL W^IOSBUF.RO 

Get completion status 

BLBC RO,EXIT 

Branch on failure 

BRB LOOP 

Reissue the read 

; Logical link was aborted. 

DONE: $DASSGN_S - ; 

; Deassign the channel 

CHAN=W ~ NETCHAN 

; Address of channel number 

; Exit with status (in RO). 

EXIT: $EXIT_S RO 

Exit with status to be displayed 
on error condition 

.END START 

Image transfer address 


8.7.4 MACRO Program for Nontransparent Task-to-Task 

Communication 

Example 8-4 illustrates the use of several of these system 
service calls for nontransparent task-to-task communication. 
CONNECT is a nontransparent MACRO source task on the 
local node that communicates with a nontransparent target task, 
DECLARNAM, on node DENVER. This example is similar to 
Example 8-2, except that the source task here uses an NCB 
and performs a nontransparent assign operation to establish 
communication with the target task. DECLARNAM is a non¬ 
transparent target task that has declared a name (that is, it 
is eligible to receive multiple inbound connection requests). 

In addition, it also uses a mailbox to receive network status 
notifications. Neither task performs useful functions. They 
are presented here only to illustrate various nontransparent 
functions. 
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Example 8-4 Nontransparent Communication Using System 
Services 


DECLARNAM 

.TITLE 
.IDENT 
.SBTTL 
.PSECT 

SNFBDEF 

SDIBDEF 

DEVDESC:.ASCID 
MAXMSG: .LONG 
BUFQUO: .LONG 
MBXDESC:.ASCID 
MAXLINKS=128 
BUFFER_SIZE=64 


DECLARNAM- NONTRANSPARENT EXAMPLE (WITH DECLARED NAME) 
/VI.0/ 

READONLY.DATA 
DECLARNAM$RDDATA 


/.NET:/ 

128 

128 

/DECLARMBX/ 


.SBTTL 
.PSECT 



NAMEDESC: 


.ASCID 


DCL.CHAN: 


. BLKW 


READWRITE.DATA 

DECLARNAM$RWDATA 

/DECLARNAM/ 

1 ; 


SHR,NOEXE,RD,NOWRT,BYTE 


Pseudo-device and descriptor 
Maximum message size 
Buffer quota 

Mailbox lognam and descriptor 
Maximum number of logical links allowed 
Size of input buffer to accept 
; messages 

SHR,NOEXE,RD,WRT,BYTE 
; Declared name & descriptor 


Word to receive declared name channel number 


DEV_CHAN: 




.BLKW 

1 


Word to receive device channel number 

MBX.CHAN 

.BLKW 

1 


Word to receive mailbox channel number 

MBXMSG: 

. BLKB 

128 


Mailbox buffer 

IOSB: 

. BLKQ 

1 


I/O status block 

AST.IOSB 

. BLKQ 

1 


I/O status block for AST 

NCBDESC: 

.LONG 

100 


Network control block descriptor 


.LONG 

NCB 



NCB: 

.BLKB 

100 


Network control block 

NFBDESC: 

.LONG 

5 


Network function block descriptor 


.LONG 

NFB 



NFB: 

.BYTE 

NFB$C_DECLNAME 


Network function block 


.LONG 

0 



PRILEN: 

.WORD 

0 


Length of buffer for $GETCHAN info 

PRIBUF: 

.LONG 

128 


Descriptor of $GETCHAN buffer 


.LONG 

PBUF 



PBUF: 

.BLKB 

128 


Buffer to receive SGETCHAN info 

COUNT: 

. BLKL 

1 


Number of table entries 

CHAN.LIST: 



Channel number list 


.BLKW 

MAXLINKS 



UNIT.LIST: 



Unit number list 


BLKW 

MAXLINKS 



IOSB.LIST: 



Read message I/O status block list 


BLKQ 

MAXLINKS 



BUFFERS: 

.BLKB 

MAXLINKS * BUFFER.SIZE 


Input buffers to put message 
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System Services 


BUF_ADR_LIST: ; List of pointers to input buffers 

OFFSET = 0 
.REPT MAXLINKS 
.ADDRESS BUFFERS + OFFSET 
OFFSET = OFFSET + BUFFER.SIZE 
.ENDR 

.SBTTL MAIN 

; + 

; This program demonstrates the use of a declared name to allow multiple 
; inbound connection requests. It is included for illustrative purposes 
; and is not intended to perform any useful work. In particular, nonnetwork 
; code is kept to a minimum (note for example, that all errors result in 
; program termination, which is an inappropriate procedure for most applications). 

.PSECT DECLARNAMSCODE 
.ENTRY START,“M<> 

; Create a temporary mailbox with the 

$CREMBX_S - 

CHAN=W“MBX_CHAN,- 
MAXMSG=W“MAXMSG,- 
BUFQUO=W“BUFQUO,- 
LOGNAM=W“MBXDESC 

BLBC RO,EXITS 


NOSHR,EXE,RD,NOWRT,BYTE 
; Main entry point 

logical name DECLARMBX. 

; Address of word to put mailbox channel 
; Address of longword with maximum message size 
; Address of longword with buffer quota 
; Address of descriptor of mailbox lognam 

; Error if LBC 


Assign a channel to a NET device and associate the mailbox with it. 


$ASSIGN_S - 

DEVNAM=W“DEVDESC,- 
CHAN=VT DCL.CHAN,- 
MBXNAM=W“MBXDESC 


Issue $ASSIGN system service request 
Address of descriptor of NET device 
Address of word to put channel number 
Address of descriptor of mailbox logical name 


BLBC RO,EXITS 


Error if LBC 


Declare a network name. 

$QIOW_S - 

CHAN=W“DCL.CHAN,- 
FUNC=#IO$_ACPCONTROL,- 
IOSB=W“IOSB,- 
P1=W“NFBDESC,- 
P2=#NAMEDESC 

BLBC RO,EXITS 

MOVZWL W“IOSB,R0 
BLBC RO,EXITS 


Issue declare name request 
Use assigned channel 
ACP QIO 

Address of I/O status block 
Address of NFB descriptor 
Address of declared name descriptor 

Error if LBC 
Get the I/O status 
Error if LBC 
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System Services 


; Issue an asynchronous read to the mailbox. 

BSBW READ_MBX ; Set up mailbox read AST 

; Now, go to sleep until someone writes to our mailbox. 

$HIBER_S ; zzzzzzz. 

EXITS: $EXIT_S RO ; Exit with status 

.SBTTL MAILBOX.AST 

.ENTRY MAILBOX_AST,~M<> ; Entry point for AST routine 


AST routine to examine the mailbox message code 
and determine the appropriate action. 

MOVZWL W~AST_IOSB,RO ; Get asynchronous I/O completion status 

BLBC RO,EXITS ; Branch on failure 


CASEB 

DISP.TAB: 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

.WORD 

BRB 

CONNECT: 

BSBW 

CMPW 

BEQL 

BSBW 

10$: BSBB 

RET 


DISCON: 

ABORT: 

EXIT: 
PATHLOST: 
PROTOCOL: 
THIRDPARTY: 


W~MBXMSG,#MSG$_AB0RT,#MSG$_NETSHUT-MSG$_ABORT 


ABORT-DISP.TAB 

CONFIRM-DISP.TAB 

CONNECT-DISP.TAB 

DISCON-DISP.TAB 

EXIT-DISP.TAB 

INTMSG-DISP.TAB 

PATHLOST-DISP.TAB 

PROTOCOL-DISP.TAB 

REJECT-DISP.TAB 

THIRDPARTY-DISP.TAB 

TIMEOUT-DISP.TAB 

NETSHUT-DISP.TAB 

Fall through on mailbox message out of range 
Unknown mailbox message encountered 

Go accept the connect request 
Was the connect request rejected? 

If rejected then do not issue the 
read 

Issue a read on the channel we 
just confirmed 

Requeue the mailbox read AST 
Return control to main program 


EXITS 

CONNECT.ACCEPT 
#I0$_ACCESS!I0$M_AB0RT,R4 
10 $ 

READ.CHAN 

READ.MBX 
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TIMEOUT: 

BSBW DISCONNECT 

BSBB READ_MBX 

RET 

NETSHUT: 

$WAKE_S 
RET 

INTMSG: 

REJECT: 

CONFIRM: 

BSBB READ.MBX 

RET 

.SBTTL READ.AST 

.ENTRY READ.AST,~M<> 

; + 

; AST routine to check the completion 
; the message received. 

MOVL 4(AP),R8 

MOVQ VT IOSB.LIST[R8].RO 

CMPW #SS$_LINKABORT,RO 

BEQL 10$ 

BLBC RO,EXITS 


; Go disconnect the link 
; Requeue the mailbox read AST 
; Return control to main 

; The network is shutting down 
; Wake the main program so that 
; it will exit 

; Ignore interrupt messages for 
; this example 

; Requeue the mailbox read AST 
; Return control to main 

; Entry point for AST routine 
status of the read and to process 


Get the index to the lists 
Get the I/O completion status 
Did the link go away? 

If EQL then ignore 
If LBC then error 


; Message is received and written into the buffer pointed to by 
; BUF_ADR_LIST[R1]. Useful code could be inserted here to process 
; the message. When complete, reissue the read on the channel and 
; then go back to point where interruption occurred. 

MOVW W~CHAN_LIST[R8],R3 ; Get the channel number 

BSBB READ.CHAN ; Reissue the read 

10$: RET ; Return from AST routine 


.SBTTL SUBROUTINES 

Subroutine to issue an asynchronous read to the mailbox with an AST. 


READ.MBX: 

$QI0_S - 

CHAN=W ~ MBX.CHAN,- 
FUNC=#I0$_READVBLK,- 
I0SB=W~AST_I0SB,- 
ASTADR=W~MAILBOX_AST,- 
P1=W~MBXMSG, - 
P2=W~MAXMSG 
BLBS RO,10$ 

BRW EXITS 

10$: RSB 


Issue read with AST 
Use assigned mailbox channel 
Read virtual block 
Address of I/O status block 
Address of AST routine 
Address of input buffer 
Length of input buffer 
Error if LBC 
Branch (failure) 

Return from subroutine 
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+ 

Subroutine to issue an asynchronous read to the channel with an AST. 


READ.CHAN: 



$QI0_S 


Issue read with AST 



CHAN=R3,- 

Use channel we just confirmed 



FUNC=#I0$_READVBLK,- 

Read virtual block 



I0SB=W~I0SB_LIST[R8] 

Address of I/O status block 



ASTADR=W~READ_AST,- 

Address of AST routine 



ASTPRM=R8,- 

Store index as AST parameter 



P1=W~BUF_ADR_LIST[R8] 

Address of input buffer 



P2=#BUFFER_SIZE 

Length of input buffer 


BLBS 

RO,10$ 

Error if LBC 


BRW 

EXITS 

Branch (failure) 

10$: 

RSB 


Return from subroutine 


.PAGE 



T 

; Subroutine to 

accept the connect request and add the channel and unit 

; numbers to the lists 



CONNECT.ACCEPT: 

MOVAB VTMBXMSG+4.R9 
MOVZBL (R9)+,R8 
ADDL2 R8,R9 
MOVZBL (R9)+,R8 
M0VC3 R8,(R9),W~NCB 
MOVL R8.VTNCBDESC 


Get address of device name count 

Get byte count of device name string 

Skip over the string 

Get byte count of info string 

Put the NCB in address NCB 

Update the NCB descriptor 


Make sure we haven't reached maximum links. 


5$: 


CMPL #MAXLINKS,W~COUNT 

BGTR 5$ 

MOVW VT DCL_CHAN,R3 

MOVZWL #IO$_ACCESS!IO$M_ABORT 
BRB 25$ 

$ASSIGN_S - 

DEVNAM=W~DEVDESC,- 
CHAN=VT DEV.CHAN,- 
MBXNAM=VTMBXDESC 
BLBS RO,10$ 

BRW EXITS 


; Have maximum number of links been reached? 

; If not, then assign a channel to NET 
; Use the original channel 
R4;Set up with connect reject code 
; Go make the reject 
; Assign a channel to the task 
; Address of NET descriptor 
; Channel number 

; Associate the mailbox with new network device 
; If LBC then error 
; Branch (failure) 
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Now, get the channel and unit numbers and put them in their respective lists. 


10$: 

$GETCHN_ 

_s - 

Issue get chan system service 



CHAN=W~DEV_CHAN,- 

Address of word containing channel number 



PRILEN=W~PRILEN, - 

Address of word to put length returned 



PRIBUF=W~PRIBUF 

Address of descriptor of buffer 


BLBS 

RO,19$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 

19$: 

CLRL 

R8 

Initialize the index 

20$: 

TSTW 

W~CHAN_LIST[R8] 

Is it empty? 


BEQL 

22$ 

Branch if an empty slot is found 


A0BLEQ 

W~C0UNT,R8,20$ 

Increment the index and try again 


BRW 

EXITS 

No empty slots? 

22$: 

M0VW 

W~DEV_CHAN,W~CHAN_LIST[R8];Put the chan number in the chan list 


MOVW 

W~PBUF+DIB$W_UNIT,W~UNIT_LIST[R8]; Put unit number in unit list 


INCL 

W~C0UNT ; 

i Increment the number of entries 

; Issue 

the connect confirm QIO. 



MOVW 

W~DEV_CHAN,R3 

Set up with address of assigned chan 


MOVZWL 

S~#IO$_ACCESS,R4 

Set up with connect accept function code 

25$: 

$QI0W_S 

- 

Issue connect confirm/reject request 



CHAN=R3,- 

Use assigned channel 



FUNC=R4,- 

Request a logical link 



I0SB=W~I0SB,- 

Address of I/O status block 



P2=#NCBDESC 

Address of NCB descriptor 


BLBS 

RO,30$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 

30$: 

MOVZWL 

W~I0SB,R0 

Get I/O completion status 


BLBS 

RO,40$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 

40$: 

RSB 


Return from subroutine 

; + 

; Subroutine to 

disconnect a channel and 

remove its entry from the lists. 

DISCONNECT: 




MOVZWL 

W~MBXMSG+2,RO 

Get the unit number 


CLRL 

R8 

Initialize the index 

5$: 

CMPW 

W~UNIT_LIST[R8],R0 

Locate the unit number in the list 


BEQL 

10$ 

If EQL then success 


AOBLEQ 

W~C0UNT,R8,5$ 

Increment the index and try again 

10$: 

MOVZWL 

W'‘CHAN_LIST [R8] ,R9 

Channel number is located 


$DASSGN. 

_S - 

Deassign the channel 



CHAN=R9 

Channel number 


BLBS 

RO,20$ 

If LBC then error 


BRW 

EXITS 

Branch (failure) 
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Example 8-4 (Cont.) 


Nontransparent Communication Using 
System Services 


The channel has been deassigned. Remove the entries from the unit and 
channel lists. 


20 $: 

DECL 

CLRW 

CLRW 

RSB 

.END 

CONNECT 

.TITLE 
.SBTTL 
.PSECT 

DEVDESC:.ASCID 
MAXMSG: .LONG 
BUFQUO: .LONG 

.SBTTL 


W"COUNT 

VTCHAN.LIST [R8] 
VTUNIT.LIST [R8] 

START 


Decrement the number of entries 
Clear the channel list entry 
Clear the unit list entry 

Return from subroutine 
Image transfer address 


CONNECT - ISSUE A CONNECT REQUEST TO DECLAR (DECLARED NAME) 
READONLY.DATA 

CONNECTSRDDATA SHR,NOEXE,RD,NOWRT,BYTE 

/_NET:/ ; Pseudo-device and descriptor 

64 ; Largest size mailbox message allowed 

64 ; Mailbox quota 

READWRITE.DATA 


.PSECT 

CONNECT$RWDATA SHR,NOEXE,RD,WRT,BYTE 

DEV.CHAN: 



. BLKW 

1 ; 

; Word to receive device channel number 

MBX_CHAN: 



.BLKW 

1 

Word to receive mailbox channel number 

MBXMSG: .BLKB 

64 

Mailbox buffer 

IOSB: .BLKQ 

1 

I/O status block 

NCBDESC:.LONG 

NCB.SIZE 

Network connect block and descriptor 

.LONG 

NCB 


NCB: .ASCII 

TDENVER::? 

Node-spec string 

.ASCII 

?"(TASK=DECLAR/? 

Task-spec string (declared name) 

.WORD 

0 

Must be zero 

.ASCII 

/"/ 

End of NCB 

NCB_SIZE=.-NCB 


Size of NCB 

.SBTTL 

MAIN 


* + 

; This program 

demonstrates how to make a connection request to a task 


that has declared a network name. It does not perform any useful work 
but does serve to illustrate DECnet nontransparent I/O. 


.PSECT 
.ENTRY 


C0NNECT$C0DE 
STARTS M<> 


NOSHR,EXE,RD,NOWRT,BYTE 
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Example 8-4 (Cont.) Nontransparent Communication Using 

System Services 


Use the Run-Time Library routine, LIB$ASN_WTH_MBX to establish 
a communication path to DECnet software in preparation for 
nontransparent I/O operations. 

This routine will create a temporary mailbox and assign a channel to it and 
assign a channel to _NET: and associate the temporary mailbox with it. 


The mailbox can be used to obtain supplementary information from 
DECnet software about logical link operations. 


PUSHAW 

W~MBX_CHAN 

PUSHAW 

W~DEV_CHAN 

PUSHAL 

W~BUFQU0 

PUSHAL 

W~MAXMSG 

PUSHAQ 

W~DEVDESC 

CALLS 

#5,LIB$ASN_WTH_MBX 

BLBS 

RO.10$ 

BRW 

EXITS 


Address to receive mailbox channel number 
Address to receive device channel number 
Mailbox quota 

Largest size mailbox message allowed 
Address of device name descriptor 
Assign channel and associate mailbox 
If LBC then error 
Branch (failure) 


Request a logical link to the remote task. 


10$: $QI0W_S - 

CHAN=W“DEV_CHAN,- 
FUNC=#I0$_ACCESS,- 
I0SB=Vri0SB,- 
P2=#NCBDESC 

BLBC R0.EXITS 

MOVZWL W“I0SB,R0 
BLBC RO,EXITS 


Issue connect initiate request 
Use assigned channel 
Request a logical link 
Address of I/O status block 
Address of NCB descriptor 

If LBC then error 

Get I/O completion status 

If LBC then error 


Established a logical link with DECLARNAM. Useful code could be inserted 
here before continuing with the disconnect. 


Disconnect the logical link by deassigning the channel. 


$DASSGN_S - 

CHAN=W ~ DEV_CHAN 
BLBC RO.EXITS 

EXITS: $EXIT_S RO 

.END START 


Issue the deassign request 

Address of word containing channel number 

If LBC then error 

Exit with status to be displayed 
on error condition 
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File Operations in a Heterogeneous 
Network Environment 


This chapter contains material to assist you in using DECnet- 
VAX Version 4.0 to initiate remote file operations in a het¬ 
erogeneous network environment. Restrictions on using 
DCL commands and RMS service calls to access files on the 
following types of remote systems are discussed in this chapter: 


VAX/VMS 
VAX/VMS 
VAX/VMS 
VAX/VMS 
VAX/VMS 
VAX/VMS 
VAX/VMS 
VAX/VMS 
VAX/VMS 


to IAS 
to P/OS 
to RSTS/E 

to RSX using RMS-based FAL 
to RSX using FCS-based FAL 
to RT-11 
to TOPS-10 
to TOPS-20 

to VAX/VMS (previous DECnet release) 


The chapter is organized by operating system type: one section 
for each heterogeneous system with which your VAX/VMS 
system running DECnet-VAX V4.0 may wish to communicate. 
Each section describes differences in file system operation be¬ 
tween the two systems and constraints on the use of VAX/VMS 
file processing commands. The restrictions on the remote file 
operations you can perform from a VAX/VMS V4.0 node to 
a particular heterogeneous node result from file system design 
differences and DECnet implementation restrictions between 
the systems. 


Specifically, the appropriate section for each remote system 
itemizes the VAX Record Management System (RMS) features 
that are supported between DECnet-VAX V4.0 systems, but 
are not supported when accessing files on the heterogeneous 
system. The section also discusses limitations on the DIGITAL 
Command Language (DCL) commands that you can use when 
communicating with the remote node. Throughout this chapter 
comments are provided to help you handle the differences in 
file system design. 


The most recent version of DECnet used by each heterogeneous 
system is represented in this chapter. 
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9.1 General DECnet-VAX Restrictions 

This section is a brief summary of VAX RMS features that are 
not supported by DECnet-VAX for remote file access. The 
list is not complete; it is meant only to highlight the more 
important differences between local and remote file access 
capabilities. For more complete information on this subject, 
refer to the description of the various RMS control blocks in the 
VAX Record Management Services Reference Manual. 

• The following VAX RMS service calls are not supported for 
network use: 

$ENTER $NXTVOL SREMOVE 

• The Terminal XAB is not supported for network operations; 
it is ignored. 

• New fields in the Protection XAB for VAX/VMS V4.0 
to support access control lists are ignored for network 
operations. 

• Only one data stream per open file is allowed. That is, the 
multi-stream (MSE) bit option of the file sharing (SHR) field 
of the FAB is not supported for network use. 

• Access to files on magnetic tapes mounted on a remote 
VAX/VMS system is not supported. You can, however, 
copy files from a local magnetic tape to disk on a remote 
node. 

• When multiple Allocation XABs are linked to the FAB, they 
must be in ascending order by area number (AID field). 
Similarly, when multiple Key Definition XABs are used, they 
must be in ascending order by key of reference (REF field). 

• File protection information may not be completely preserved 
if the two nodes do not fully support each other's protection 
attributes. 

An example of this incompatibility occurs between RSX- 
11M/RSX-11M-PLUS and VAX/VMS systems. Although 
both systems represent their protection masks as RWED, 
RSX-11M/RSX-11 M-PLUS interprets that as Read, Write, 
Extend, and Delete, while VAX/VMS interprets RWED 
as Read, Write, Execute, and Delete. This results in the 
"E" protection field being unmappable between these two 
systems. 


9-2 






File Operations in a Heterogeneous Network Environment 


9.2 VAX/VMS to IAS Network Operation 

This section pertains to a VAX/VMS node communicating with 
an IAS node running DECnet-IAS V3.0. The discussion focuses 
on file operations initiated from the VAX/VMS node to access 
remote files by means of the FAL at the IAS node. 


9.2.1 File System Constraints 

The restrictions described below are related to incompatible 
features in file system design between the two systems. 


9.2.1.1 File Formats and Access Modes 

The following types of files and access methods are not sup¬ 
ported by VAX/VMS when communicating with an IAS node: 

• File organizations and record formats: 

Sequential Stream (STM) 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable with fixed control (VFC) 
where fixed header size is not 2 bytes 

Relative All formats 

Indexed All formats 

• Record attributes: 

Print file carriage control (PRN) 

• File access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 

You can copy a sequential file in VFC format from a VAX/VMS 
node to an IAS node provided that the file has a 2-byte fixed 
header with a carriage control attribute other than print file. 

To transfer a file having print file carriage control, such as a 
VAX/VMS batch log file, use the command 

$ CONVERT/FDL=VAR.FDL input-file output-file 
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where the FDL control file VAR.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT variable 

CARRIAGE.CONTROL carriage_return 

The CONVERT command and associated FDL control file will 
transform the input file to variable-length format with implied 
carriage control and copy it to the remote node according to the 
output file specification. 


9.2.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and an IAS node: 

• VAX RMS service calls: 

SDELETE $DISPLAY $EXTEND $FIND 

$FREE $READ $RELEASE $RENAME 

$REWIND $SPACE STRUNCATE SUPDATE 

$WRITE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
DEQ (default extend quantity) field 


9.2.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote IAS system is 

node::device:[directory]name.type;version 


The following are major differences in syntax between file 
specifications used on IAS and on VAX/VMS: 

• IAS does not support dollar sign ($) and underscore (_) 
characters in file name components. 
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• IAS does not recognize the percent sign (%) as a valid 
wildcard character. 

• The directory component of an IAS file specification cannot 
be a named directory list, such as [A.B.C]; it must be in UIC 
(user identification code) format, such as [100,3]. 

• The file name component has a maximum length of nine 
characters and the file type cannot exceed three characters. 
IAS systems will return an error if you specify a longer file 
name or file type. 

• IAS uses octal version numbers in file specifications whereas 
VAX/VMS uses decimal version numbers. 


9.2.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following are not supported between VAX/VMS 
and an IAS node: 

• ANALYZE/RMS-FILE 

• BACKUP 

• OPEN/WRITE 

• RENAME 


9.2.2.1 APPEND 

In using the APPEND command, you are limited to appending 
one local input file to the output file residing on the IAS node. 


9.2.22 COPY 

The /EXTENSION and /PROTECTION qualifiers for the COPY 
command are not supported and will be ignored if specified. 

File creation date and time information is not preserved on a 
file copy operation to an IAS node where wild cards are used in 
the output file specification. Instead, the current date and time 
is used as the file creation date and time. 

Because the IAS system uses octal version numbers in file 
specifications, an attempt to copy a file with a version number 
containing an 8 or 9 is rejected by the remote system, as shown 
in the following example: 
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$ COPY A.DAT;9 IAS::* *.* 

7.C0PY-E-0PEN0UT, error opening _IAS: :A.DAT;9 as output 
-RMS-F-FNM, error in file name 


There are two ways to circumvent this problem. You can either 
specify an appropriate octal version number in the output 
file specification, or you can specify a null or zero version 
number in the output file specification to force highest version 
number processing on the remote node. This latter technique is 
particularly useful when several files are copied with one DCL 
command. For example: 

$ COPY A.DAT;9 IAS::A.DAT;11 
$ COPY B.DAT;28 IAS: 

$ COPY B.DAT;28 IAS::*.*;0 
$ COPY *.DAT IAS: 


9.3 VAX/VMS to P/OS Network Operation 

This section pertains to a VAX/VMS node communicating with 
an P/OS node running DECnet-PRO VI.0. The discussion 
focuses on file operations initiated from the VAX/VMS node, to 
access remote files by means of the FAL at the P/OS node. 


9.3.1 File System Constraints 

The restrictions described below are related to incompatible 
features in file system design between the two systems. 


9.3.1.1 File Formats and Access Modes 

The following types of file and record attributes are not sup¬ 
ported by VAX/VMS when communicating with a P/OS 
node: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 

Indexed All prologue 3 formats 

With 64-bit binary (BN8) key types 
With 64-bit integer (IN8) key types 
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• Record attributes: 

(Record attributes are compatible) 

• File access modes: 

(Modes are compatible) 


9.3.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and a P/OS node: 

• VAX RMS service calls: 

SRELEASE 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
SCF (submit command file) bit of FOP field 
SPL (spool file) bit of FOP field 


9.3.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote P/OS system is: 

node::device:[directory]name.type;version 


The following are major differences in syntax between file 

specifications used on P/OS and VAX/VMS: 

• P/OS does not support dollar sign ($) and underscore (__) 
characters in file name components. 

• The directory component in a P/OS file specification cannot 
be a named directory list, such as [A.B.C]; it can be a single 
directory name, such as [USERFILES], or it can be expressed 
in UIC (user identification code) format, such as [15,1]. 

• The file name component has a maximum length of nine 
characters and the file type cannot exceed three characters. 
P/OS systems will return an error if you specify a longer 
file name or file type. 
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9.3.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following are not supported between VAX/VMS 
and a P/OS node: 

• OPEN/WRITE 

• PRINT/REMOTE 

• SUBMIT/REMOTE 


9.4 VAX/VMS to RSTS/E Network Operation 

This section pertains to a VAX/VMS node communicating 
with a RSTS/E node running DECnet/E V3.0. The discussion 
focuses on file operations initiated from the VAX/VMS node, to 
access remote files by means of the FAL at the RSTS/E node. 


9.4.1 File System Constraints 

The restrictions described below are related to incompatible 
features in file system design between the two systems. 


9.4.1.1 File Formats and Access Modes 

The following types of file and access methods are not sup¬ 
ported by VAX/VMS when communicating with a RSTS/E 
node: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 

Indexed All prologue 3 formats 

With 64-bit binary (BN8) key types 
With 64-bit integer (IN8) key types 


• Record attributes: 

(Attributes are compatible) 
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• File access modes: 

Random access by key value 
Random access by record file address 

DECnet/E does not support record mode access to indexed 
files; it supports only block I/O access to indexed files. 

Note that an attempt to access an indexed file located on a 
RSTS/E node in record mode will result in an RMS-F-BUG_ 
DAP error instead of an RMS-F-SUPPORT error. 


9.4.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and a RSTS/E node: 

• VAX RMS service calls: 

$DISPLAY $EXTEND $FREE $RELEASE 

$RENAME $SPACE $TRUNCATE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
DEQ (default extend quantity) field 


9.4.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote RSTS/E system is 

node::device:[directory]name.type 


The following are major differences in syntax between file 
specifications used on RSTS/E and on VAX/VMS: 

• RSTS/E does not support dollar sign ($) and underscore (_) 
characters in file name components, except for the special 
use of the dollar sign at the start of a file name. 

• RSTS/E does not recognize the percent sign (%) as a valid 
wildcard character. 
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• The directory component of a RSTS/E file specification 
cannot be a named directory list, such as [A.B.C]; it must 
be in UIC (user identification code) format, such as [1,2]. 
RSTS/E systems, however, express UICs in decimal radix, 
whereas VAX/VMS systems use octal numbers. On the 
RSTS/E system, the UIC is referred to as a PPN (project 
programmer number). 

To access a RSTS/E file whose directory component in PPN 
format contains decimal digits, use the quoted string form of 
the file specification. For example: 

$ TYPE RSTS::"SY:[9,18]TEST.DAT" 

• The file name component has a maximum length of six 
characters and the file type cannot exceed three characters. 

If you specify a longer file name, RSTS/E will truncate the 
name to six characters. 

• RSTS/E does not support version numbers. It will accept 
a file specification containing a version number without 
returning an error, but will ignore the version number. 


9.4.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following are not supported between VAX/VMS 
and a RSTS/E node: 

• PURGE 

• RENAME 


9.4.2.1 APPEND 

In using the APPEND command, you are limited to appending 
one local input file to an output file on the RSTS/E node. 
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9.4.2.2 


COPY 


The /EXTENSION and /PROTECTION qualifiers for the COPY 
command are not supported and will be ignored if specified. 

File creation date and time information is not preserved on a 
file copy operation to a RSTS/E node where wildcards are used 
in the output file specification. Instead, the current date and 
time is used as the file creation date and time. 

Because RSTS/E does not support version numbers in file 
specifications (it will ignore any version number supplied), an 
attempt to copy a file with an explicit version number will fail if 
a file with the same name and type already exists at the RSTS 
/E node. For example, if a file with the name RSTS::TEST.DAT 
already exists on the remote node, an attempt to update it by 
copying a new version of that file to the node will produce the 
following results: 

$ COPY TEST.DAT;2 RSTS::*.* 

'/.COPY-E-OPENOUT, error opening _RSTS: : TEST. DAT; 2 as output 
-RMS-E-FEX, file already exists, not superseded 



9.4.2.3 


DELETE 


If you use the DELETE command with a wildcard file specifica¬ 
tion to delete several files from a directory on a remote RSTS/E 
node, the operation may appear to complete successfully even 
though some of the files may remain in the directory. This 
behavior is caused by a file system incompatibility in the way 
VAX/VMS and RSTS/E perform wildcard file deletion opera¬ 
tions. This problem will occur only if the remote directory has 
at least 30 files cataloged. 

To determine if all the files you specified have been deleted 
successfully, issue a DIRECTORY command to examine the 
remote directory. Then repeat the wildcard DELETE command 
if necessary to remove unwanted files. If the number of files 
you are attempting to delete is small, using the /LOG qualifier 
with the DELETE command may help you to determine if all 
the files have been deleted. 
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9.4.2.4 DIRECTORY 

When you issue a DIRECTORY/FULL command to examine 
a RSTS/E file, the information displayed will differ from 
that which is displayed for a VAX/VMS file in the following 
respects: 

• The file owner is displayed as [0,0] if the owner of the file is 
identified by a UIC that contains decimal digits. 

• The file revision number shown will be either 0 or 1. A 
revision number of 0 indicates the file has not been revised; 
a revision number of 1 indicates the file has been revised. 

• Under the attributes of an indexed file, information about 
the number of keys, the number of areas, and the prologue 
version number of the file is not displayed. This information 
is omitted because the RSTS/E FAL does not return file 
attribute information stored in the prologue portion of an 
indexed file. 

• Under the attributes of a relative file, the maximum record 
number is displayed as 0. 


9.4.2.5 DUMP/RECORDS and TYPE Commands 

Because RSTS/E does not support record mode access (non¬ 
block I/O access) to indexed files, you cannot use the DCL 
commands DUMP/RECORDS and TYPE to examine indexed 
files located on the remote RSTS/E node. 


9.5 VAX/VMS to RSX Network Operation Using 
RMS-Based FAL 

This section pertains to a VAX/VMS node communicating with 
an RSX node running either DECnet-llM V4.0 or DECnet- 
11M-PLUS V2.0 where the RSX File Access Listener (FAL) calls 
RMS-11 to perform local file operations. The discussion focuses 
on file operations initiated from the VAX/VMS node, to access 
remote files by means of the FAL at the RSX node. 


9.5.1 File System Constraints 

The restrictions described below are related to incompatible 
features in file system design between the two systems. 
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9.5.1.1 File Formats and Access Modes 

The following types of file and record attributes are not sup¬ 
ported by VAX/VMS when communicating with an RSX node 
running the RMS-based FAL: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 

Indexed All prologue 3 formats 

With 64-bit binary (BN8) key types 
With 64-bit integer (IN8) key types 

• Record attributes: 

(Record attributes are compatible) 

• File access modes: 

(Modes are compatible) 


9.5.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and an RMS-based RSX node: 

• VAX RMS service calls: 

$RELEASE 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP 


9.5.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote RSX-11M or RSX-11M-PLUS system is: 

node::device:[directory]name.type;version 


The following are major differences in syntax between file 
specifications used on RSX and VAX/VMS: 

• RSX systems do not support dollar sign ($) and underscore 
(_) characters in file name components. 
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• The directory component in an RSX file specification cannot 
be a named directory list, such as [A.B.C]; it must be in UIC 
(user identification code) format, such as [15,1]. 

• The file name component has a maximum length of nine 
characters and the file type cannot exceed three characters. 
RSX systems will return an error if you specify a longer file 
name or file type. 

• RSX systems use octal version numbers in file specifications 
whereas VAX/VMS uses decimal version numbers. 


9.5.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following is not supported between VAX/VMS 
and an RMS-based RSX node: 

• OPEN/WRITE 


9.5.2.1 COPY 

Because RSX-11M and RSX-11M-PLUS systems use octal 
version numbers in file specifications, an attempt to copy a file 
with a version number containing an 8 or 9 is rejected by the 
remote system. For example: 

$ COPY A.DAT;9 RSX::*.* 

*/,COPY-E-OPENOUT, error opening RSX: :A.DAT;9 as output 
-RMS-F-FNM, error in file name 

There are two ways to circumvent this problem. You can 
specify an appropriate octal version number in the output 
file specification, or you can specify a null or zero version 
number in the output file specification to force highest version 
number processing on the remote node. This latter technique is 
particularly useful when several files are copied with one DCL 
command. For example: 

$ COPY A.DAT;9 RSX::A.DAT;11 
$ COPY B.DAT;28 RSX: 

$ COPY B.DAT;28 RSX::*.*;0 
$ COPY *.DAT RSX: 


9-14 








File Operations in a Heterogeneous Network Environment 


9.6 VAX/VMS to RSX Network Operation Using 
FCS-Based FAL 

This section pertains to a VAX/VMS node communicating with 
an RSX node running DECnet-llM V4.0 or DECnet-llM- 
PLUS V2.0 where the RSX FAL calls the File Control Services 
(FCS-11) to perform file operations. The discussion focuses 
on file operations initiated from the VAX/VMS node to access 
remote files by means of the FAL at the RSX node. 


9.6.1 File System Constraints 

The restrictions described below are related to incompatible 
features in file system design between the two systems. 


9.6.1.1 File Formats and Access Modes 

The following types of files and access methods are not sup¬ 
ported by VAX/VMS when communicating with an RSX node 
running the FCS-based FAL: 

• File organizations and record formats: 

Sequential Stream (STM) 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable with fixed control (VFC) 
where fixed header size is not 2 bytes 

Relative All formats 

Indexed All formats 

• Record attributes: 

Print file carriage control (PRN) 

• File access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 
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You can copy a sequential file in VFC format from a VAX/VMS 
node to an FCS-based RSX node provided that the file has 
a 2-byte fixed header with a carriage control attribute other 
than print file. To transfer a file having print file carriage 
control, such as a VAX/VMS batch log file, use the command 

$ CONVERT/FDL=VAR.FDL input-file output-file 

where the FDL control file VAR.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT variable 

CARRIAGE.CONTROL carriage.return 

The CONVERT command and associated FDL control file will 
transform the input file to variable-length format with implied 
carriage control and copy it to the remote node according to the 
output file specification. 


9.6.1.2 


VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and an FCS-based RSX node: 


• VAX RMS service calls: 

SDELETE $DISPLAY SEXTEND $FIND 

SFREE SREAD $RELEASE $RENAME 

$REWIND $SPACE $TRUNCATE SUPDATE 

$WRITE 

• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

CBT (contiguous-best-try) bit of FOP field 
DEQ (default extension quantity) field 
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9.6.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote RSX-11M or RSX-11M-PLUS system is: 

node::device:[directory]name.type;version 


The following are major differences in syntax between file 

specifications used on RSX and VAX/VMS: 

• RSX systems do not support dollar sign ($) and underscore 
(_) characters in file name components. 

• The directory component in an RSX file specification cannot 
be a named directory list, such as [A.B.C]; it must be in UIC 
(user identification code) format, such as [15,1]. 

• The file name component has a maximum length of nine 
characters and the file type cannot exceed three characters. 
RSX systems will return an error if you specify a longer file 
name or file type. 

• RSX systems use octal version numbers in file specifications 
whereas VAX/VMS uses decimal version numbers. 


9.6.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following are not supported between VAX/VMS 
and an FCS-based RSX node: 

• ANALYZE/RMS-FILE 

• BACKUP 

• OPEN/WRITE 

• RENAME 


9.6.2.1 APPEND 

In using the APPEND command, you are limited to appending 
one local input file to an output file residing on the FCS-based 
RSX node. 


9-17 








File Operations in a Heterogeneous Network Environment 


9.6.2.2 COPY 

The /EXTENSION and /PROTECTION qualifiers for the COPY 
command are not supported and will be ignored if specified. 

File creation date and time information is not preserved on a 
file copy operation to an RSX node where wildcards are used in 
the output file specification. Instead, the current date and time 
is used as the file creation date and time. 

Because RSX-11M and RSX-11M-PLUS systems use octal 
version numbers in file specifications, an attempt to copy a file 
with a version number containing an 8 or 9 is rejected by the 
remote system, as shown below: 

$ COPY A.DAT;9 RSX::*.* 

7.C0PY-E-0PEN0UT. error opening RSX: : A. DAT; 9 as output 
-RMS-F-FNM, error in file name 

There are two ways to circumvent this problem. You can either 
specify an appropriate octal version number in the output 
file specification, or you can specify a null or zero version 
number in the output file specification to force highest version 
number processing on the remote node. This latter technique is 
particularly useful when several files are copied with one DCL 
command. For example: 

$ COPY A.DAT;9 RSX::A.DAT;11 
$ COPY B.DAT;28 RSX: 

$ COPY B.DAT;28 RSX::*.*;0 
$ COPY *.DAT RSX::*.*;0 


9.7 VAX/VMS to RT—11 Network Operations 

This section pertains to a VAX/VMS node communicating 
with a RT-11 node running DECnet-RT V2.1. The discussion 
focuses on file operations initiated from the VAX/VMS node, to 
access remote files by means of the FAL at the RT node. 
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9.7.1 File System Constraints 

The file systems used by RT-11 and VAX/VMS are dissimilar 
in many respects. A fundamental difference between them 
involves the handling of file attribute information. When a file 
is created on a VAX/VMS system, attribute information about 
the file is stored in a header block on disk for use when the file 
is subsequently opened. The implication is that the structure 
of an established file cannot change. In contrast, RT-11 does 
not save attribute information such as file format with a file; 
it expects the user to provide this information when the file is 
opened. File attribute information, however, is not an input to 
VAX RMS when a file is opened. 

To provide transparent access to files on a remote RT-11 
system, VAX RMS restricts the types of files that you can create 
and open on the remote node. When you access an RT-11 
file in record mode, VAX RMS treats the file as having stream 
format. Block I/O access is permitted; the remote file is viewed 
as having fixed length 512 byte records where virtual block 
number is translated to relative record number. 


9.7.1.1 


File Formats and Access Modes 

The following types of files and access methods are not sup¬ 
ported by VAX/VMS when communicating with an RT node: 

• File organizations and record formats: 


Sequential 


Relative 

Indexed 


Fixed length (FIX) without implied 
carriage control 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable length (VAR) without implied 
carriage control 

Variable with fixed control (VFC) 

All formats 
All formats 


• Record attributes: 


FORTRAN carriage control (FTN) 

Print file carriage control (PRN) 

None specified (embedded carriage control) 
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• Record access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 

For record mode access, the only file type in common between 
the two systems is a sequential file in STM (stream) format. For 
convenience, however, when you are transferring a file to an 
RT-11 node, VAX RMS will automatically convert a VAX/VMS 
sequential file with fixed or variable format and implied carriage 
control to a sequential file with stream format and embedded 
carriage control. This automatic conversion is performed during 
a file create operation, and VAX RMS returns an alternate 
success code (RMS$_CVT_STM) to indicate that the file format 
has been modified. 

Note also that when a stream format file is retrieved from 
an RT-11 node, VAX RMS automatically changes the record 
attribute from embedded carriage control to implied carriage 
control. 

In general, text files created by the SOS Editor without line 
numbers being saved or by the EDT Editor can be copied to an 
RT-11 system. VAX/VMS batch log files and files created by 
the SOS Editor with line numbers intact, however, are stored in 
VFC format and cannot be copied to an RT-11 system in that 
form. To transfer this type of file, use the DCL command 

$ CONVERT/FDL=STM.FDL input-file output-file 

where the FDL control file STM.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT stream 

CARRIAGE.CONTROL none 

The CONVERT command and associated FDL control file 
will transform the input file to stream format with embedded 
carriage control and copy it to the remote node according to the 
output file specification. 
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9.7.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and an RT-11 node: 

• VAX RMS service calls: 

SDELETE SDISPLAY $EXTEND $FIND 

SFREE $RELEASE $RENAME $REWIND 

$SPACE $TRUNCATE $UPDATE 

• RMS extended attribute blocks: 

Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

ALQ (allocation quantity) field 

DEQ (default extend quantity) field 

CBT (contiguous-best-try) bit of FOP field 

CTG (contiguous) bit of FOP field 

SCF (submit command file) bit of FOP field 

SPL (spool file) bit of FOP field 

• Significant fields and bit options of the RAB: 

EOF (position to end of file) bit of ROP field 


9.7.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote RT-11 system is 

node::device:name.type 


The following are major differences in syntax between file 

specifications on RT-11 and VAX/VMS: 

• RT-11 does not support dollar sign ($) and underscore (_) 
characters in file name components. 

• RT-11 does not recognize the percent sign (%) as a valid 
wildcard character. 

• RT-11 does not have a directory component in its file 
specification. 
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• The file name component has a maximum length of six 
characters and the file type cannot exceed three characters. 

If you specify a longer file name or file type, RT-11 will 
return an error. 

• RT-11 does not support version numbers. Specification of a 
version number, however, is permitted when you refer to an 
RT-11 file, because VAX RMS discards any version number 
before sending the file specified to the RT-11 FAL. 


9.7.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following are not supported between VAX/VMS 
and an RT-11 node: 

• ANALYZE/RMS_FILE 

• APPEND 

• BACKUP 

• OPEN/WRITE 

• PRINT/REMOTE 

• PURGE 

• RENAME 

• SUBMIT/REMOTE 


9.7.2.1 COPY 

The /ALLOCATION, /CONTIGUOUS, /EXTENSION, and 
/PROTECTION qualifiers for the COPY command are not 
supported and will be ignored if specified. 

Using COPY to merge several files into a single output file is 
not supported. 

RT-11 does not support version numbers in file specifications 
and supersedes files by default. Therefore, if you attempt to 
copy a file with the same name and type as one that already 
exists on the remote RT-11 node, the new file will supersede 
the old one. No warning message is displayed. 


9-22 










File Operations in a Heterogeneous Network Environment 


9.7.2.2 DELETE 

The DCL command DELETE requires that you specify an 
explicit or wildcard version number in the file specification. 
However, since RT-11 does not accept a file specification 
containing a version number, VAX RMS removes the version 
number before sending the file specification to the RT-11 
system. To satisfy the requirements of both systems, specify a 
null version number in the file specification, as shown below. 

$ DELETE RT::TEST.DAT; 


9.7.3 Miscellaneous 

Normally DECnet-RT is generated to support a maximum of 
two logical links. However, depending on the speed of the 
communications line and the load on the VAX/VMS and RT- 
11 systems, two links may not be sufficient to perform certain 
wildcard operations initiated from the VAX/VMS node. As 
a result, use of DCL commands such as COPY, TYPE, and 
DELETE to perform wildcard file retrieval or wildcard file 
deletion operations may fail due to insufficient resources. This 
problem can be circumvented if the RT-11 system is generated 
to support a maximum of three logical links. 


9.8 VAX/VMS to TOPS-10 Network Operations 

This section pertains to a VAX/VMS node communicating with 
a TOPS-IO node running DECnet-10 V4.0. The discussion 
focuses on file operations initiated from the VAX/VMS node, to 
access remote files by means of the FAL at the TOPS-IO node. 


9.8.1 File System Constraints 

The file systems used by TOPS-IO and VAX/VMS are dissimi¬ 
lar in many respects. A fundamental difference between them 
involves the handling of file attribute information. When a file 
is created on a VAX/VMS system, attribute information about 
the file is stored in a header block on disk for use when the file 
is subsequently opened. The implication is that the structure of 
an established file cannot change. In contrast, TOPS-IO does 
not save attribute information such as file format with a file; 
it expects the user to provide this information when the file is 
opened. File attribute information, however, is not an input to 
VAX RMS when a file is opened. 
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To provide transparent access to files on a remote TOPS-10 
system, VAX RMS restricts the types of files that you can create 
and open on the remote node. When you access a TOPS-10 
file in record mode, VAX RMS treats the file as having stream 
format. 


9.8.1.1 


File Formats and Access Modes 

Because of differences in file system design, the following types 
of files and access methods are not supported by VAX/VMS 
when communicating with a TOPS-10 node: 


• File organizations and record formats: 

Sequential Fixed length (FIX) without implied 

carriage control 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable length (VAR) without implied 
carriage control 

Variable with fixed control (VFC) 
Relative All formats 

Indexed All formats 


• Record attributes: 

FORTRAN carriage control (FTN) 

Print file carriage control (PRN) 

None specified (embedded carriage control) 

• Record access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 


For record mode access, the only file type in common between 
the two systems is a sequential file in STM (stream) format. 

For convenience, however, when you are transferring a file 
to a TOPS-10 node, VAX RMS will automatically convert a 
VAX/VMS sequential file with fixed or variable format and 
implied carriage control to a sequential file with stream format 
and embedded carriage control. This automatic conversion is 
performed during a file create operation, and VAX RMS returns 
an alternate success code (RMS$_CVT_STM) to indicate that 
the file format has been modified. 
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Note also that when a stream format file is retrieved from a 
TOPS-IO node, VAX RMS automatically changes the record 
attribute from embedded carriage control to implied carriage 
control. 

In general, text files created by the SOS Editor without line 
numbers being saved or by the EDT Editor can be copied to a 
TOPS-IO system. VAX/VMS batch log files and files created by 
the SOS Editor with line numbers intact, however, are stored in 
VFC format, and cannot be copied in that form to a TOPS-IO 
system. To transfer this type of file, use the DCL command 

$ CONVERT/FDL=STM.FDL input-file output-file 


where the FDL control file STM.FDL contains 

FILE 

ORGANIZATION sequential 

RECORD 

FORMAT stream 

CARRIAGE.CONTROL none 

The CONVERT command and associated FDL control file 
will transform the input file to stream format with embedded 
carriage control and copy it to the remote node according to the 
output file specification. 


9.8.1.2 


VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and a TOPS-IO node: 


• VAX RMS service calls: 

SDELETE $DISPLAY 

SFREE $READ 

$REWIND $SPACE 
$WRITE 


$EXTEND $FIND 

$RELEASE $RENAME 

$TRUNCATE SUPDATE 


• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 
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• Significant fields and bit options of the FAB: 

ALQ (allocation quantity) field 

DEQ (default extend quantity) field 

CBT (contiguous-best-try) bit of FOP field 


9.8.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote TOPS-10 system is 

node::device[directory]name.type 


The following are the major differences in syntax between file 

specifications on TOPS-10 and on VAX/VMS: 

• The directory component of a TOPS-10 file specification 
is in PPN (project programmer number) format, such as 
[3655,7031], where the two numbers are in octal radix. 

The directory component can also be in extended PPN 
format containing up to five levels of subdirectories. An 
example of a directory component in extended PPN format 
is [10,20,A,B,C,D,E]. 

VAX/VMS cannot parse directory components in PPN for¬ 
mat (with numbers larger than 377 octal) or handle extended 
PPN formats containing subdirectories. The DECnet-10 im¬ 
plementation, however, will accept directory components 
using period (.) instead of comma (,) delimiters, and will 
convert commas to periods when returning file specifi¬ 
cations to VAX/VMS systems. Consequently, when you 
enter a file specification for a remote TOPS-10 system, use 
the VAX/VMS named directory list format for express¬ 
ing TOPS-10 PPNs and extended PPNs. For example, 
use [3655.7031] or [10.20.A.B.C.D.E] to specify a directory 
component. 

• The file name component has a maximum length of six 
characters and the file type cannot exceed three characters. 

If you specify a longer file name, TOPS-10 will truncate the 
name to six characters. 

• TOPS-10 does not support version numbers. It will accept 
a file specification containing a version number without 
returning an error, but will ignore the version number. 
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9.8.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following are not supported between VAX/VMS 
and a TOPS-IO node: 

• ANALYZE/RMS-FILE 

• APPEND 

• BACKUP 

• OPEN/WRITE 

• RENAME 


9.8.2.1 COPY 

The /ALLOCATION and /EXTENSION qualifiers to the COPY 
command are not supported and will be ignored if specified. 


9.8.2.2 DIRECTORY 

When you issue a DIRECTORY/FULL command to examine 
a TOPS-10 file, the information displayed will differ in the 
following respects from that which is displayed for a VAX/VMS 
file: 

• The file owner is displayed as [0,0] to indicate that this 
information is not available. 

• The file revision number is not shown and file revision date 
and time information is not available from the TOPS-10 
system. 

• The blocks used and blocks allocated values displayed, 
which indicate the size of the file, refer to 128-word pages 
(providing 640 bytes of storage), not 512-byte blocks. 


9.9 VAX/VMS to TOPS-20 Network Operations 

This section pertains to a VAX/VMS node communicating with 
a TOPS-20 node running DECnet-20 V3.0. The discussion 
focuses on file operations initiated from the VAX/VMS node, to 
access remote files by means of the FAL at the TOPS-20 node. 
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9.9.1 File System Constraints 

The file systems used by TOPS-20 and VAX/VMS are dissimi¬ 
lar in many respects. A fundamental difference between them 
involves the handling of file attribute information. When a file 
is created on a VAX/VMS system, attribute information about 
the file is stored in a header block on disk for use when the file 
is subsequently opened. The implication is that the structure of 
an established file cannot change. In contrast, TOPS-20 does 
not save attribute information such as file format with a file; 
it expects the user to provide this information when the file is 
opened. File attribute information, however, is not an input to 
VAX RMS when a file is opened. 

To provide transparent access to files on a remote TOPS-20 
system, VAX RMS restricts the types of files that you can create 
and open on the remote node. When you access a TOPS-20 
file in record mode, VAX RMS treats the file as having stream 
format. Although block I/O is supported by DECnet-20, it is 
not supported between VAX/VMS and TOPS-20 because the 
block sizes are different. 


9.9.1.1 


File Formats and Access Modes 

Because of differences in file system design, the following types 
of files and access methods are not supported by VAX/VMS 
when communicating with a TOPS-20 node: 


• File organizations and record formats: 


Sequential 


Relative 

Indexed 


Fixed length (FIX) without implied 
carriage control 

Stream_CR (STMCR) 

Stream_LF (STMLF) 

Variable length (VAR) without implied 
carriage control 

Variable with fixed control (VFC) 

All formats 
All formats 


• Record attributes: 
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• Record access modes: 

Random access by relative record number 
Random access by key value 
Random access by record file address 
Block I/O 

For record mode access, the only file type in common between 
the two systems is a sequential file in STM (stream) format. 

For convenience, however, when you are transferring a file 
to a TOPS-20 node, VAX RMS will automatically convert a 
VAX/VMS sequential file with fixed or variable format and 
implied carriage control to a sequential file with stream format 
and embedded carriage control. This automatic conversion is 
performed during a file create operation, and VAX RMS returns 
an alternate success code (RMS$_CVT_STM) to indicate that 
the file format has been modified. 

Note also that when a stream format file is retrieved from a 
TOPS-20 node, VAX RMS automatically changes the record 
attribute from embedded carriage control to implied carriage 
control. 

In general, text files created by the SOS Editor without line 
numbers being saved or by the EDT Editor can be copied to a 
TOPS-20 system. VAX/VMS batch log files and files created by 
the SOS Editor with line numbers intact, however, are stored in 
VFC format, and cannot be copied in that form to a TOPS-20 
system. To transfer this type of file, use the DCL command 

$ CONVERT/FDL=STM.FDL input-file output-file 

where the FDL control file STM.FDL contains 
FILE 

ORGANIZATION sequential 

RECORD 

FORMAT stream 

CARRIAGE.CONTROL none 

The CONVERT command and associated FDL control file 
will transform the input file to stream format with embedded 
carriage control and copy it to the remote node according to the 
output file specification. 
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9.9.1.2 


VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS nodes, are not supported between a VAX/VMS 
node and a TOPS-20 node: 


• VAX RMS service calls: 

$DELETE SDISPLAY 

$FREE $READ 

SREWIND $SPACE 
$WRITE 


$EXTEND $FIND 

$RELEASE $RENAME 

$TRUNCATE $UPDATE 


• RMS extended attribute blocks: 

Allocation XAB 
Key Definition XAB 
Summary XAB 

• Significant fields and bit options of the FAB: 

ALQ (allocation quantity) field 
DEQ (default extend quantity) field 
CBT (contiguous-best-try) bit of FOP field 
CTG (contiguous) bit of FOP field 

• Significant fields and bit options of the RAB: 

EOF (position to end of file) bit of ROP field 


9.9.1.3 File Specifications 

The general format of a file specification for naming a file on a 

remote TOPS-20 system is 

node::device<directory>name.type.version 

The following are the major differences in syntax between file 

specifications on TOPS-20 and on VAX/VMS: 

• TOPS-20 uses angle brackets (<>) to delimit the directory 
string instead of square brackets ([]). To facilitate communi¬ 
cation with TOPS-20, VAX RMS recognizes angle brackets 
as valid directory component delimiters. 

• TOPS-20 uses the period (.) to delimit the version number 
instead of the semicolon (;). However, you can specify 
either a period or a semicolon because VAX RMS converts 
a semicolon version number delimiter to a period before 
sending the file specification to the TOPS-20 FAL. 
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9.9.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following are not supported between VAX/VMS 
and a TOPS-20 node: 

• ANALYZE/RMS—FILE 

• APPEND 

• BACKUP 

• OPEN/WRITE 

• RENAME 


9.9.2.1 COPY 

The /ALLOCATION, /CONTIGUOUS, /EXTENSION, and 
/PROTECTION qualifiers to the COPY command are not 
supported and will be ignored if specified. 

File creation date and time is not preserved during a file copy 
operation. 

Using COPY to merge several files into a single output file is 
not supported. 


9.9.2.2 DIRECTORY 

When you issue a DIRECTORY/FULL command to examine 
a TOPS-20 file, the information displayed will differ in the 
following respects from that which is displayed for a VAX/VMS 
file: 

• The file owner is displayed as [0,0] to indicate that this 
information is not available. 

• The file revision number is not shown. 

• The blocks used and blocks allocated values displayed, 
which indicate the size of the file, refer to 128-word pages 
(providing 640 bytes of storage), not 512-byte blocks. 

• TOPS-20 does not have the equivalent of world protection, 
so this attribute is displayed as a null string. 


9—31 









File Operations in a Heterogeneous Network Environment 


9.10 VAX/VMS to VAX/VMS (Previous DECnet Release) 

This section pertains to file operations initiated on a VAX/VMS 
V4.0 node running DECnet-VAX V4.0 where the remote system 
is a VAX/VMS V3.4 node running DECnet-VAX V3.1. 


9.10.1 File System Constraints 

The restrictions described below are related to new features 
in DECnet-VAX V4.0 for remote file access that were not 
supported in DECnet-VAX V3.1. 


9.10.1.1 File Formats and Access Modes 

The following types of files and access methods are not sup¬ 
ported by VAX/VMS when communicating with a VAX/VMS 
V3.n node: 

• File organizations and record formats: 

Sequential Stream_CR (STMCR) 

Stream_LF (STMLF) 

Indexed With 64-bit binary (BN8) key types 

With 64-bit integer (IN8) key types 

• Record attributes: 

(Record attributes are compatible) 

• File access modes: 

(Modes are compatible) 


9.10.1.2 VAX RMS Interface 

The following VAX RMS features, supported between two 
VAX/VMS V4.0 nodes, are not supported between a VAX/VMS 
V4.0 node and a VAX/VMS V3.n node: 

• VAX RMS service calls: 

$RENAME 

• RMS extended attribute blocks: 

(No differences) 


9-32 









File Operations in a Heterogeneous Network Environment 


• Significant fields and bit options of the FAB: 
(No differences) 


9.10.1.3 File Specifications 

The general format of a file specification for naming a file on a 
remote VAX/VMS V3.n system is 

node::device:[directory]name.type;version 


The following are major differences in syntax between file 
specifications used on VAX/VMS V3.n and on VAX/VMS V4.0: 

• VAX/VMS V3.n systems do not support dollar sign ($) and 
underscore (_) characters in file name components. 

• The file name component has a maximum length of nine 
characters and the file type cannot exceed three characters. 
VAX/VMS V3.n systems will return an error if you specify a 
longer file name or file type. 


9.10.2 DCL Considerations 

Of the VAX/VMS DCL commands that can be used over the 
network, the following is not supported between a VAX/VMS 
V4.0 node and a VAX/VMS V3.n node: 

• RENAME 
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Phase IV DECnet supports area routing, which permits the 
configuration of networks in which the nodes are grouped into 
areas. This appendix presents recommendations and guidelines 
for configuring networks that use area routing. It illustrates the 
guidelines with an example of the design of a multiple-area 
network, and indicates the NCP commands required to build 
the configuration database for this network. The appendix also 
recommends a procedure for converting an existing network 
to a multiple-area network. The next section of the appendix 
describes problems that can occur when configuring an area- 
based network, and includes suggestions for solving these 
problems. The final section discusses area routing on the 
Ethernet. 

Area routing concepts are described in detail in Section 2.4. 
Area routing techniques enable configuration of a network 
consisting of a number of areas; each area is a group of nodes 
that forms a subnetwork. DECnet supports routing of packets 
within areas and a second level of routing between areas. The 
router that performs routing within an area is called a level 1 
router; the router that performs routing to and from other areas 
as well as within its own area is called a level 2 router (or area 
router). 

Each level 1 router keeps information on the state of all nodes 
in its area, but not on the state of nodes outside its area. It 
routes all packets addressed to nodes outside its area to the 
nearest level 2 router. Each level 2 router keeps information on 
the least-cost path to areas throughout the network, as well as 
the state of the nodes in its own area. When a level 1 router 
receives a packet destined for a node in another area, it uses 
level 1 routing to send the packet to the nearest level 2 router 
in its own area. The level 2 router forwards the packet along 
the least-cost path to the nearest level 2 router outside its area. 
The packet is transmitted along a level 2 path to the level 2 
router in the destination area; this level 2 router sends the 
packet by level 1 routers to the destination node. 
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Thus, a basic reason for dividing a network into multiple areas 
would be to reduce the amount of routing traffic that would 
occur in a single-area network. 


A.1 Area Routing Configuration Guidelines 

Configuration of a network that consists of multiple areas 
is more complex than configuration of a network that, by 
default, consists of a single area. The design of a multiple- 
area network introduces a second, higher level of routing that 
links the areas. Designing a network for area routing involves 
awareness of certain network topological restrictions unique 
to area routing configurations. The area routing configuration 
guidelines presented below are based on these restrictions. The 
guidelines are intended to prevent problems such as loss of 
routing path, isolation of nodes, or incorrect routing of packets. 
These potential problems are discussed in Section A.5. 

When you configure a multiple-area network, you should 
follow these guidelines: 

• Each node must belong in only one area. This restriction 
applies to all nodes in the network. Phase III nodes as 
well as Phase IV nodes. Phase III nodes must be logically 
associated with a single area even though they are not 
assigned an area number by network management, and 
must not have circuits outside the area. 

• Only a level 2 router can establish a circuit with a node in 
another area, thus enabling communication between the 
areas. A level 1 router cannot have any circuits outside its 
own area. 

• Within a network, the level 2 routers must form a subnet¬ 
work; that is, they must be connected in such a way that 
they create a network of their own. There must be a level 
2 routing path between any pair of level 2 routers across 
the network. Level 1 routers do not forward level 2 routing 
information. 

• Treat each area as though it were a separate network. Each 
area must be physically intact and capable of running on its 
own. Within the area, there must be a level 2 path between 
any pair of level 2 routers. 
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• Provide enough redundancy within each area and between 
areas to avoid having a single point of failure in the net¬ 
work. For redundancy within an area, you could include 
more than one level 2 router and provide for alternate paths 
between nodes. This redundancy will prevent loss of the 
routing path within the area or isolation of any one node. 
For redundancy between areas, you could provide for al¬ 
ternate paths between areas so that loss of a line does not 
disconnect any area from the rest of the network. Com¬ 
plete redundancy may not be feasible, however, for certain 
networks, such as small networks. 

• Place all Phase III nodes on the periphery in each area. Do 
not place a Phase III node in a path between two Phase IV 
nodes. A Phase III node cannot communicate directly with 
nodes in other areas or with nodes in the same area that 
have addresses greater than 255. 

• Do not link a Phase III node in one area with a node in 
another area. Such a connection could lead to area leakage, 
a problem described in Section A.5.2.2. 

The recommended approach to designing a multiple-area net¬ 
work configuration is to begin by designing the level 2 routers, 
area by area, into a level 2 subnetwork. Then, in each area, 
add the level 1 routers. Finally, add the end nodes required to 
complete each area. This design approach is illustrated below. 


A.2 Designing a Multiple-Area Network 

This section demonstrates the use of the configuration guide¬ 
lines in designing a multiple-area network. The goal of the 
design process is to build a robust, redundant network that will 
not be subject to a single point of failure. 

Figure A-l shows the level 2 routers as a subnetwork of a 
multiple-area network. For purposes of illustration, DMR lines 
are used to connect level 2 routers within each area and DMC 
lines to connect level 2 routers in different areas. In each area, 
the level 2 routers are configured in pairs for redundancy and 
connected by enough DMR lines so that the loss of one DMR 
line does not prevent the flow of level 2 routing traffic through 
the area. Redundancy between different areas is achieved by 
the way in which the DMC lines connect level 2 routers in the 
different areas. If one of the DMC lines fails, level 2 routing 
traffic can still reach each area by an alternate path. In area 9, 
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the redundant level 2 routers that form part of a VAXcluster are 
connected by a Cl line. 

Figure A-2 shows the next stage of the design process: adding 
the level 1 routers and the end nodes to each area. The figure 
does not include all the nodes that might be required to make 
the network complete. It illustrates only a few typical uses of 
level 1 routers and end nodes, indicating the way in which you 
could add such nodes to the level 2 subnetwork to complete the 
network design. 

In Figure A-2, in area 7, an end node and a level 1 router 
are attached directly to the first Ethernet. Micro VMS end 
nodes are connected to the level 1 router by means of DDCMP 
asynchronous lines. Another end node is connected to a level 
2 router attached to the second Ethernet (lower left) in area 7. 
Because this end node is not on a routing path between level 
2 routers, it could possibly be a Phase III end node. In area 9, 
two level 1 routers are added to the redundant level 2 routers 
in a VAXcluster. 

The network design shown in Figure A-2 ensures a robust 
network not vulnerable to a line or node failure that could 
isolate or bring down an area. A fully redundant multiple-area 
network, such as that in Figure A-2, may not be practical for 
smaller networks, however. Redundancy is a desirable design 
goal, not a requirement, in a multiple-area network. 

When you complete the design of a multiple-area network, 
begin network configuration by configuring each area sepa¬ 
rately, as though it were a network by itself. An example of the 
NCP commands required to configure area 7 of the network in 
Figure A-2 is given in the following section. Once you have 
configured all areas in the network and they are running and 
stable, connect the areas. 
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Figure A-1 Level 2 Router Subnetwork of a Multiple-Area 

Network 
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Figure A—2 Example of Multiple-Area Network Design 
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A.3 Sample Multiple-Area Network Configuration 

The example below illustrates how you can use NCP com¬ 
mands to configure a multiple-area network. It lists the NCP 
commands required to build the permanent database for one 
area of the large multiple-area network shown in Figure A-2, 
and indicates how to complete the network configuration. 

This example builds a database for a network configuration of 
twelve nodes in area 7, as depicted in Figure A-3. Area 7 is 
connected to areas 8 and 9. The database being built is for node 
A. Similar commands would be issued to create the database 
for each of the other nodes in area 7, and each of the nodes in 
areas 8 and 9. 
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Figure A—3 Area 7 of a Multiple-Area Network 
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Define executor-specific parameters for local node A. 

Note that the TYPE parameter for the executor node 
defaults to either NONROUTING IV or ROUTING IV, depending 
on whether an end node or full function key has been 
installed. In this example, node A needs to be a level 2 
router, so the TYPE parameter is set accordingly. 

DEFINE EXECUTOR ADDRESS 7.1 - 

BUFFER SIZE 576 - 
STATE ON - 
TYPE AREA - 
DEFAULT PROXY BOTH 


Define common node parameters for the local node. Be 
sure to add the NETNONPRIV user to your system 
authorization file by using the Authorize Utility. 

DEFINE EXECUTOR NAME A - 

NONPRIVILEGED - 

USER NETNONPRIV - 
PASSWORD NONPRIV - 


Define the remaining nodes. Note that no default outbound 
access control information is specified. This assumes that 
the default access control information will be supplied by 


! each 

remote 

node when it receives an inbound connection, 

! as a 

result 

of a proxy login on the target node. 

DEFINE 

NODE 

B 

ADDRESS 

7.2 

DEFINE 

NODE 

C 

ADDRESS 

7.3 

DEFINE 

NODE 

D 

ADDRESS 

7.4 

DEFINE 

NODE 

E 

ADDRESS 

7.5 

DEFINE 

NODE 

F 

ADDRESS 

7.6 

DEFINE 

NODE 

G 

ADDRESS 

7.7 

DEFINE 

NODE 

H 

ADDRESS 

7.8 

DEFINE 

NODE 

I 

ADDRESS 

7.9 

DEFINE 

NODE 

J 

ADDRESS 

7.10 

DEFINE 

NODE 

K 

ADDRESS 

7.11 

DEFINE 

NODE 

L 

ADDRESS 

7.12 


or 


A—9 








Area Routing Configuration 


If node L is a Phase III node, it would be necessary 
to specify routing initialization passwords to 
initialize this node. Using the number of the area in 
which the Phase III node resides as part of the password 
will avoid accidental connection to another area. 

Define a receive password for node L as follows: 

DEFINE NODE L RECEIVE PASSWORD AREA7 
In this case, on node L, the transmit password would be 
set to match: 

DEFINE NODE A TRANSMIT PASSWORD AREA7 ! (on node L) 

Note that although nodes M and N reside in different 
areas, no special action is needed in defining them. 
Continue defining nodes in other areas in this fashion. 

DEFINE NODE M ADDRESS 8.3 
DEFINE NODE N ADDRESS 9.42 

Set up the line and circuit for the Ethernet connected 
to node A. 

DEFINE LINE UNA-0 STATE ON 
DEFINE CIRCUIT UNA-0 STATE ON 

Set up the line and circuit for each DMR connected to 
node A. Note that a DMR line is treated like a DMC line. 

DEFINE LINE DMC-1 STATE ON 
DEFINE CIRCUIT DMC-1 STATE ON 
DEFINE LINE DMC-2 STATE ON 
DEFINE CIRCUIT DMC-2 STATE ON 

Set up the line and circuit for the DMC connected to 
node A. Because the DMC leads to another area, you 
may want to leave this circuit and line in the OFF state 
while you are initially configuring your area, turning 
them on only after the connections within your area 
have been tested. 

DEFINE LINE DMC-0 STATE ON 
DEFINE CIRCUIT DMC-0 STATE ON 

The object database does not need to be defined, since it 
defaults to the standard list of objects known to VAX/VMS. 

Define the transmitter-related logging parameters. 

DEFINE LOGGING MONITOR KNOWN EVENTS 

Define receiver-related logging parameters. 

DEFINE LOGGING MONITOR STATE ON 
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A.4 Converting an Existing Network to a Multiple-Area 
Network 

Converting an existing single-area network to a multiple- 
area network requires careful planning. Because the network 
addresses of existing nodes will change, there may be a period 
during which some nodes are unreachable while the conversion 
is underway. The following steps illustrate an approach that 
can keep this disruption to a minimum. 

1 Plan ahead. Completely define what the entire network 
topology will be with multiple areas. Make sure the topol¬ 
ogy follows the guidelines listed in Section A.l. Decide 
which nodes should be level 2 routers, level 1 routers, and 
end nodes. 

2 If the new design requires that some nodes be moved, 
make the required changes before you begin converting 
node addresses. (For example, the redesign may involve 
reconnecting a Phase III node so that it is not in a path 
between two Phase IV nodes.) 

3 Create new node databases. Without modifying the existing 
permanent node databases, create a new copy of the node 
database on each node in the network. This is most easily 
done as follows for DECnet-VAX nodes: 

a Use the logical name NETNODE to point to the working 
copy of the node database you are creating. This logical 
name will be translated when NCP is reading the perma¬ 
nent database, and the default version of 
NETNODE.DAT in SYS$SYSTEM will remain un¬ 
touched. Redefine the logical name as follows: 

$ COPY SYSSSYSTEM:NETNODE.DAT - 
_ SYSSMANAGER:NEWNETNODE.DAT 
$ DEFINE NETNODE SYSSMANAGER:NEWNETNODE.DAT 
$ RUN SYSSSYSTEM:NCP 
NCP> 

When the NCP prompt appears, enter the changes, 
which will be made to the new file. 

b In your remote node database, change the addresses 
of existing nodes in the network to reflect the new 
topology with areas. If you are adding new nodes 
to the network (for example, if two existing separate 
networks are to be merged), include their new addresses 
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in your database now. Make sure these changes are 
only made to the working copy of the database, and 
not to SYS$SYSTEM:NETNODE.DAT. For now, the 
database changes need to be made only on one node in 
the network. Also, issue the command 

NCP> PURGE EXECUTOR ALL 

and add the executor node as a separate node, as follows: 

NCP>DEFINE NODE local__node__name... 

c When SYS$MANAGER:NEWNETNODE.DAT correctly 
reflects the new topology (with the exception of the 
executor information), copy it to the SYS$MANAGER 
directory on each node in the network. (Note that 
this should be done only for nodes which are running 
the same version of VAX/VMS. If you have different 
versions in the network, the conversion procedure 
should be followed independently for each version.) 

On each VAX/VMS node on the network, using the 
logical name NETNODE as described in step 3a above, 
define the executor parameters in NEWNETNODE.DAT 
as follows: 

NCP>PURGE NODE local_node_name ALL 

NCP>DEFINE EXECUTOR NODE local__node__name ... 

Using the NCP command DEFINE EXECUTOR, set up 
each local node with the correct area and node address, 
correct executor type (nonrouting IV, routing IV, or area), 
and other executor parameters. (Consult the existing 
copy of NETNODE.DAT if necessary.) 

Similarly, convert the node database on each non-VAX 
node in your network using the tools available for each 
implementation. 

4 Shut down the network and bring it up again with the new 
database. 

This is the only part of the conversion process which 
benefits from real-time cooperation among the nodes in 
your network. If this level of coordination is not feasible, 
then avoid using area number 1 for any area in the revised 
network, since node address duplications might occur during 
the transition period. 
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At approximately the same time, have each node in the 
network shut down DECnet. It is not necessary to shut 
down the operating system. Use the command 

NCP>SET EXECUTOR NODE SHUT 

When all nodes have shut down DECnet (or after an agreed- 
upon interval during which all nodes should have shut 
down DECnet), rename the new copy of the database and 
restart the network at each node: 

$ RENAME SYS$MANAGERiNEWNETNODE.DAT - 
_ SYSSSYSTEM:NETNODE.DAT 
$ @SYS$MANAGER:STARTNET 

Note that if your node is on an Ethernet to which applica¬ 
tions other than DECnet (such as LAT) are connected, these 
applications should also be shut down along with DECnet, 
and then restarted after DECnet is restarted. This step is 
necessary because DECnet will be changing the Ethernet 
physical address of your node to reflect the new executor 
node address (see Section 3.3.3.1). 

5 Use NCP to monitor the reconfigured network. 

Depending on the size of the network and the care with which 
the conversion was done, there may be a period of debugging 
the network to ensure that all desired connections have been 
made. You can simplify debugging the conversion if you can 
run each area separately for a while before connecting them. 
You can do this by turning the circuits between level 2 routers 
in different areas to the OFF state in the new copy of the 
database. Once you are confident that an area is operating to 
your satisfaction, you can turn on the circuits joining this area 
to its neighboring areas. Of course, while the interarea circuits 
are off, nodes in those areas will not be accessible to nodes in 
other areas. This circumstance may be viewed as a tradeoff to 
reduce the number of variables during the conversion. 


A.5 Problems in Configuring a Multiple-Area Network 

The use of area routing techniques in configuring a network can 
lead to certain problems that may not be readily identifiable. 
This section describes some problems related to violation of the 
area routing configuration guidelines presented in Section A.l, 
and explains how to solve these problems. 
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A.5.1 


Partitioned Area Problem 

Improper configuration of the network topology for a multiple- 
area network can result in a failure condition that can cause 
traffic to be incorrectly routed and/or lost. The problem is 
called area partitioning; it occurs when an area is broken into 
separate parts as the result of the failure of one or more lines 
or nodes. As a consequence of partitioning, a node may be 
isolated within an area. 

Figure A-4 illustrates an improper network design, in which 
an area is vulnerable to partitioning if a single line should fail. 
All circuit costs in Figure A-4 are equal to 1. Node C in area 3 
attempts to communicate with node D in area 4. If either link 
w or x fails, there is no problem because the remaining path 
into area 4 provides a route to node D. If link y or z fails, the 
level 2 router in area 3 will find the path to the level 2 router in 
area 4 on the basis of the least-cost algorithm; the path would 
be from node C to node B to node A. Because link y or z is 
down, however, it is not possible to get to the destination node 
D. 

When the initial connection is attempted, the network turns on 
the "return to sender" bit and sends a message to the sender 
indicating the node is unreachable. If the two nodes have 
already established a link before the connection breaks, the 
sender will time out, because the network will not route back 
traffic once it arrives at the destination area. Thus a node in an 
area is isolated because of a line failure. 

Figure A-4 illustrates another problem. If link z is down and 
node D wants to create a link to node B, the path that node D 
chooses is to route through area 2 and then to node B. On the 
return trip, however, node B will attempt to send the reply to 
node A, but link z is down, and therefore the reply will not be 
delivered to node D. 

The solution to the problem of area partitioning is to treat each 
area as a separate network when configuring a multiple-area 
network. Designing an area as a straight-line configuration, as 
in area 4 in the figure, should be avoided. Also, all the level 
2 routers in a given area should be linked in a level 2 routing 
path; a level 1 router should not be included on the same path. 
In the configuration in Figure A-4, installing a link between 
nodes A and D would provide for an alternate path between 
nodes in the same area. 
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Figure A—4 Partitioned Area Problem 



AREA 2 


AREA 3 
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A.5.2 Problems in Mixed Phase Ill/Phase IV Networks 

In a Phase IV multiple-area network. Phase III nodes can be 
included provided certain rules are followed: Phase III nodes 
in a multiple-area network must not be in the routing path 
between Phase IV nodes and must not be linked to nodes 
outside their own area. These limitations are based on the 
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following restrictions under which Phase III nodes operate in a 

Phase IV network: 

• DECnet-VAX Phase III nodes cannot assume a node address 
greater than 255, and cannot directly address a node with 

a node address greater than 255. They also cannot route 
through traffic for nodes with addresses greater than 255. 
(Note that this limit may vary for other DECnet Phase III 
nodes, up to a maximum possible address of 1023.) 

• Phase III nodes cannot recognize area numbers in node 
addresses. A Phase III node cannot assume an area address, 
directly address a node outside its own area, or route 
through traffic for nodes in other areas. 

• Phase III nodes cannot be connected directly to an Ethernet. 

• Phase III nodes must use routing initialization passwords 
when they are initialized in a Phase IV network (see Sec¬ 
tion A.5.2.2). 


The node address is represented in different ways in Phases III 
and IV. In Phase III a node address is represented by a single 
decimal number, such as 99. For DECnet-VAX, the maximum 
node address of a Phase III node is 255. In Phase IV a node 
address is represented by a number in the format 

area-number.node-number 

where the maximum area-number is 63 and the maximum 
node-number is 1023. If Phase IV node number 99 is in area 
33, its node address is 33.99. (If a Phase IV network is not 
configured into areas, node number 99, by default, is in area 
number 1 and is represented in the database by the node 
address 1.99.) 

Whenever a Phase III node is brought up in a Phase IV 
multiple-area network, the physical link is initialized with 
the Phase III protocol and all references to the area number are 
dropped. Routing in the network is affected in different ways, 
depending on the direction in which traffic is flowing: 

• If traffic is going from a Phase IV node to the Phase III 
node, the area number is dropped from the node address. 
For example, when node address 19.201 is passed to a Phase 
III node, the node address becomes 201. 


A—16 




Area Routing Configuration 


• If traffic is going from a Phase III node to a Phase IV node, 
the area number of the Phase IV node is added to the node 
address. For example, if node address 143 is sent to Phase 
IV node 75.5, the node address 143 becomes 75.143. 

• If a packet is routed through a Phase III node, the area 
number is dropped from both the source and destination 
node addresses in the routing header of the packet. 


A.5.2.1 Problem of a Phase III Node in a Phase IV Path 

An example of the problem caused by placing a Phase III node 
in the routing path between two Phase IV nodes in the same 
area is illustrated in Figure A-5. 

No problem occurs if the entire logical link path is within a 
single area and if none of the nodes have node numbers greater 
than 255. For example, for node 4.88 to send a packet to node 
4.45, the packet first goes to node 22 (the Phase III node has no 
area number even though it is in area 4). Node 22 discards the 
area number from the destination node address 4.45, making it 
address 45, and from the source node address 4.88, making it 
address 88. The packet is then forwarded to node 4.45, which 
adds its own area number to the destination address, making it 
4.45, and to the source address 88, making it 4.88. 

During the return trip from node 4.45 to 4.88, the packet 
(with source address 4.45 and destination address 4.88) goes 
through node 22 and loses the area numbers from the source 
and destination node addresses in its routing header. When the 
packet arrives at its destination, node 4.88 adds its own area 
number to the node addresses in the routing header, making 
the source address 4.45 and the destination address 4.88. 

A problem occurs, however, during communication between 
nodes in different areas, when the routing path in one area 
includes a Phase III node between two Phase IV nodes. In the 
example in Figure A-5, if node 2.72 wants to send a packet to 
node 4.45, the packet goes from node 2.72 to node 4.88 and 
then to node 22, which drops the area number from both the 
source and destination addresses in the routing header, making 
the source address 72 and the destination address 45. Node 
22 then sends the packet to the destination, node 4.45, which 
adds its area number to the source address, making it 4.72, 
and to the destination address, making it 4.45. The problem 
arises during the return trip. Node 4.45 attempts to respond by 
sending a packet addressed to destination node 4.72 instead of 
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Figure A-5 Problem of Phase III Node In Phase IV Path 
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2.72. If a node with address 4.72 does exist, the return packet is 
incorrectly delivered to that node. Node 2.72 does not receive a 
reply and eventually times out. 



A—18 
























Area Routing Configuration 



A.5.2.2 


Area Leakage Problem 

When a Phase III node is included in a Phase IV network 
that has been divided into multiple areas, the Phase III node 
should not be connected to a node outside its own area (as in 
Figure A-6). A Phase III node drops the area number from a 
node address. Permitting a Phase III node to have a link to 
another area causes a problem known as "area leakage." When 
the Phase III node builds its routing database, it includes the 
node addresses of adjacent nodes minus their area numbers. 
This incorrect information is then transmitted (or "leaked" ) 
across the area boundaries. This problem occurs whether the 
Phase IV nodes are level 1 or level 2 routers. 


Figure A-6 Area Leakage Problem 
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In Figure A-6, node R is a Phase III node with links to nodes 
in areas 12 and 14. Node R will build a routing database 
that contains the addresses of nodes P, Q, and S, but the area 
numbers will be missing from the node addresses. Node R will 
send routing updates to all adjacent nodes, without recognizing 
area boundaries. Thus node R will send routing information 
about nodes P and Q (minus the correct area designation) to 
node S. Node S will assume that nodes P and Q are nodes in its 
own area that have the addresses 12.6 and 12.7, respectively, 
instead of the correct addresses 14.6 and 14.7. Similarly, node 
R will send the address of node S (minus its area number) to 
nodes P and Q; nodes P and Q will assume that node S is in 
their own area and has the address 14.5 rather than the correct 
address 12.5. 

Routing initialization passwords are required when a Phase III 
node is initialized in a Phase IV network (see Section 2.10.1 
for a description of the passwords). If no password is specified 
during routing initialization, a specific event class message 
will be generated, indicating that a password is required or 
is mismatched. If the network manager has turned on the 
event logger, he or she can read these messages to learn 
which Phase III nodes have not been initialized. The network 
manager can use this information to prevent Phase III nodes 
from linking to nodes outside their own areas, or to identify 
which Phase III nodes need to have the transmit password set. 
It is recommended that the number of the area in which the 
node resides be used in the password, to prevent accidental 
connection to a node in a wrong area. 

Note that this technique will not locate Phase III nodes im¬ 
properly linked to nodes in other areas if the Phase III nodes 
were configured using routing initialization passwords before 
conversion to area routing, unless the passwords were changed 
as recommended during the conversion. 
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A.6 Area Routing on an Ethernet 

Phase IV DECnet supports configuration of multiple areas on an 
Ethernet. This configuration results in higher message overhead 
because a packet must be routed through two level 2 routers 
rather than being delivered directly to the destination node. 
Figure A-7 shows two areas sharing the same Ethernet cable. 
When a node in area 5 wishes to communicate with a node in 
area 7, the packet is routed through the two level 2 routers. 

For example, if node 5.3 sends a packet to node 7.8, the packet 
follows this path: 

• Node 5.3 to node 5.2 (source to its nearest level 2 router) 

• Node 5.2 to node 7.4 (level 2 router to level 2 router) 

• Node 7.4 to node 7.8 (level 2 router to destination) 


Figure A-7 Area Routing on an Ethernet 


AREA 5 AREA 7 

(5.2) (7.4) 



(5.3) (5.7) (7.1) (7.3) (7.8) 


ZK-2001-84 


A—21 






























Glossary 


access control: Validating connect, login, or file-access requests to 
determine whether they can be accepted. User name and password 
provide the most common means of access control. 

account name: A string that identifies a particular account used to 
accumulate data on a job's resource use. This name is the user's 
accounting charge number, not the user's UIC. 

active component: A component whose operational state is other 
than OFF. The ACTIVE keyword can be used with the SHOW or 
LIST commands to display information about active lines, circuits, 
nodes, and logging. 

adjacent node: A node removed from the local node by a single 
physical line. 

area: A group of nodes in a network that can run independently as a 
subnetwork. 

area router: A level 2 router. 

area routing: A technique for grouping the nodes in a network into 
areas for routing purposes. Routing in a multiple-area network is 
hierarchical, with one level of routing within an area (called level 1 
routing) and a second, higher level of routing between areas (called 
level 2 routing). 

asynchronous transmission: A mode of data transmission in which 
the time intervals between transmitted characters may be of unequal 
length. Asynchronous transmission most commonly occurs over 
terminal lines. 

bandwidth: The range of frequencies assigned to a channel or system 
(that is, the difference expressed in Hertz between the highest and 
lowest frequencies of a band). 

bilateral closed user group (BCUG): An optional packet switching 
data network (PSDN) facility that restricts a pair of DTEs to 
communicating with each other. 
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broadcast addressing: A special type of multicast addressing, in 
which all nodes are to receive a message. 

broadcast circuit: A circuit on which multiple nodes are connected 
and on which exists a method for transmitting a message that will be 
received by multiple receivers. 

carrier sense: A signal provided by the Physical layer to indicate 
that one or more stations (nodes) are currently transmitting on the 
Ethernet channel. 

Carrier Sense, Multiple Access with Collision Detect 

(CSMA/CD): A link management procedure used by the Ethernet. 
Allows multiple stations to access the broadcast channel at will, 
avoids contention by means of carrier sense and deference, 
and resolves contention by means of collision detection and 
retransmission. 

CCITT: Comite Consultatif International Telegraphique et 
Telephonique. An international consultative committee that 
sets international communications usage standards. 

channel: A means of transmission. For VAX PSI, a logical path 
between a DTE and a DCE over which data is transmitted. Each 
channel is identified by a unique reference number called a logical 
channel number (LCN). 

characteristics: A display type for the SHOW and LIST commands. 

It refers to static information about a component that is kept in either 
the volatile or permanent database. Such information may include 
parameters defined for that component by either the SET or DEFINE 
command. 

circuit: Virtual communication path between nodes or DTEs. Circuits 
operate over physical lines and are the medium on which all I/O 
occurs. X.25 circuits are virtual circuits. 

closed user group (CUG): An optional PSDN facility that restricts 
two or more DTEs in the same group to communicating with each 
other. 

collision: Multiple transmissions overlapping in the physical channel, 
resulting in garbled data and necessitating retransmission. 

collision detect: A signal provided by the Physical layer to the 
Data Link layer to indicate that one or more stations (nodes) are 
contending with the local station's transmission. 
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command node: The node from which an NCP command is issued. 

component: An element in the network that can be controlled and 
monitored. Components include lines, circuits, nodes, modules, 
logging, and objects. Components form part of the NCP command 
syntax. 

configuration database: The combination of both the permanent 
and the volatile databases. It consists of information about the local 
node, and all nodes, modules, circuits, lines, and objects in the 
network. 

congestion loss: A condition in which data packets are lost when 
Routing is unable to buffer them. 

connector node: A node which serves as an X.25 gateway to permit 
VAX/VMS host nodes to access a packet switching data network. 

control station: The node at the controlling end of a multipoint 
circuit. The control station controls the tributaries for that circuit. 

cost: An integer value assigned to a circuit between two adjacent 
nodes. According to the routing algorithm, packets are routed on 
paths with the lowest cost. 

counters: Performance and error statistics kept for a component, such 
as lines or nodes. 

data circuit-terminating equipment (DCE): A CCITT X.25 term 
referring to the network equipment that establishes, maintains and 
terminates a connection and handles the signal conversion and 
coding between the data terminal equipment and the network. The 
switching exchange of the network to which DTEs are connected. (In 
non-X.25 usage, the term is synonymous with modem.) 

data link mapping (DLM): Capability of using an X.25 virtual circuit 
as a DECnet data link. 

data terminal equipment (DTE): An X.25 term referring to the user's 
equipment (computer or terminal) connected to a DCE on a packet 
switching data network for the purpose of sending and/or receiving 
data. 

datagram: A unit of data sent over the network that is handled 
independently of all other units of data so far as the network is 
concerned. When a route header is added, a datagram becomes a 
packet. 
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designated router: A routing node on the Ethernet selected to 
perform routing services on behalf of end nodes. 

disconnect abort: Nontransparent tasks can deaccess a logical link 
via a disconnect abort operation without deassigning the channel. 
This form of disconnection indicates to the receiver that not all 
messages sent have necessarily been received. 

downline system load: A DECnet-VAX function that allows an 
unattended target node to receive an operating system file image 
from another node. 

downline task load: A function that allows a remote target node to 
receive an RSX-11S task from another node. 

end node: A node that can receive packets addressed to it and send 
packets to other nodes, but cannot route packets through from other 
nodes. Also called a nonrouting node. 

event: A network or system-specific occurrence for which the logging 
component maintains a record. 

event class: A particular classification of events. Generally, this 
classification follows the DNA architectural layers; some layers may 
contain more than one class. Class also includes the identification of 
system-specific events. 

event type: A particular form of event that is unique within an event 
class. 

executor node: The node at which an NCP command actually 
executes. 

frame: A unit delimited by flags that includes a header, used by 
the link level to exchange packets as well as control and error 
information between the DTE and the DCE on a packet switching 
data network. 

handshaking sequence: The exchange of logical link connection 
information between two tasks. This exchange takes place to enable 
the successful completion of a logical link connection. 

hardware address: For an Ethernet device, the unique 

Ethernet physical address associated with a particular Ethernet 
communications controller (usually in read-only memory) by the 
manufacturer. 
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hop: The logical distance between two nodes. One hop is the distance 
from one node to an adjacent node. 

host node: For DECnet, a node that provides services for another 
node (for example, the host node supplies program image files for a 
downline load). 

For VAX PSI, a node that accesses a packet switching data network 
by means of an X.25 multihost connector node. 

inbound connection: The term refers to the fact that a task receives 
logical link connection requests. 

interrupt: For VAX PSI, a packet, sent through a PSDN, that bypasses 
normal flow control procedures used by data packets. 

interrupt message: During nontransparent task-to-task 
communication, a user-generated message sent outside the 
normal exchange of data messages. This usage of the term interrupt 
is contrary to the normal usage, which means to designate a software 
or hardware interrupt mechanism. 

known component: The classification for one or more of the same 
components. This classification includes all active and inactive 
occurrences of the component type. For example, known nodes 
include all active and inactive nodes in the network. 

level 1 router: A node that can send and receive packets, and route 
packets from one node to another, only within a single area. 

level 2 router: A node that can send and receive packets, and route 
packets from one node to another, within its own area and between 
areas. Also known as an area router. 

line: The network management component that provides a distinct 
physical data path. 

Link Access Protocol (LAP): A set of procedures used for link 
control. X.25 defines two sets of procedures: 

• LAP—The DTE/DCE interface is defined as operating in two-way 
simultaneous Asynchronous Response Mode (ARM) with the DTE 
and DCE containing a Primary and Secondary function. 

• LAPB—The DTE/DCE interface is defined as operating in 
two-way Asynchronous Balanced Mode (ABM). 

local node: The node at which you are physically located. 
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logical channel: A logical link between a DTE and its DCE. The 
physical communications line between a DTE and DCE is divided 
into a set of logical channels. 

logical channel number (LCN): A unique reference number that 
identifies a logical channel. A DTE recognizes a virtual circuit by its 
associated LCN. 

logical link: A carrier of a single stream of full-duplex traffic between 
two user-level processes. 

logging: The network management component that routes event data 
to logging sinks such as a console or file. 

logging console: A logging sink that is to receive a human-readable 
record of events. Typically, a logging console is a terminal or a 
user-specified file. 

logging file: A logging sink that is to receive a machine-readable 
record of events for later retrieval. The logging file is user defined. 

logging monitor: A logging sink that is to receive a machine-readable 
record of events for possible real-time decision making. Typically, 
the logging monitor is a user-defined program. 

loop node: A local node that is associated with a particular line and 
is treated as if it were a remote node. All traffic to the loop node is 
sent over the associated line. 

maximum visits: The maximum number of nodes through which a 
packet can be routed before reaching its destination. 

module: A network management component. 

multiaccess channel: A medium (for example, Ethernet) on which 
many transmitters contend for access. 

multicast addressing: An addressing mode in which a given 
message packet is targeted to a group of logically related nodes. 

multicast group address: An address assigned to a number of nodes 
on an Ethernet and used to send a message to all nodes in the group 
in a single transmission. 

multipoint circuit: A circuit connecting two systems, with one of the 
systems (the control station) controlling the circuit, and the other 
system serving as a tributary. 
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network connect block (NCB): For DECnet, a user-generated data 
structure used in a nontransparent task to identify a remote task and 
optionally send user data in calls to request, accept, or reject a logical 
link connection. 

For VAX PSI, a block that contains the information necessary to set 
up an X.25 virtual circuit or to accept or reject a request to set up an 
X.25 virtual circuit. 

network status notifications: Notifications that provide information 
about the state of both logical and physical links over which two 
tasks communicate. A nontransparent task can use this information 
to take appropriate action under conditions such as third-party 
disconnections and a partner's exiting before I/O completion. 

network task: A nontransparent task that is able to process multiple 
inbound connection requests; that is, it has declared a network name 
or object number. 

node: A network management component that supports DECnet 
software. 

node address: The required, unique, numeric identification of a 
specific node in the network. 

node name: An optional alphanumeric identification associated with 
a node address in a strict one-to-one mapping. A node name must 
contain at least one alphabetic character. 

nonprivileged: In DECnet-VAX terminology, this term means no 
privileges in addition to NETMBX and TMPMBX. NETMBX is the 
minimal requirement for any network activity. 

nonrouting node: An end node. 

object: A DECnet-VAX process that receives a logical link request. It 
performs a specific network function (a nonzero object such as FAL 
or NML), or is a user-defined image for a special-purpose application 
(a zero-numbered object). 

A VAX PSI management component that contains records to specify 
account information for incoming calls and to specify a command 
procedure that is initiated when the incoming call arrives. 

outbound connection: The term refers to the fact that a task sends 
logical link connection requests. 
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packet: A unit of data to be routed from a source node to a 

destination node. For VAX PSI, the unit of data switched through a 
PSDN; normally a user data field accompanied by a header carrying 
destination and other information. 

packet assembly/disassembly (PAD) facility: A device at a 
PSDN node that allows access from an asynchronous terminal. The 
terminal connects to the PAD and the PAD puts the terminal's input 
data into packets (assembles) and takes the terminal's output data 
out of packets (disassembles). 

packet switching: A data transmission process, utilizing addressed 
packets, whereby a channel is occupied only for the duration of 
transmission of the packet. 

packet switching data network (PSDN): A set of equipment 
and interconnecting links that provides a packet-switching 
communications service to subscribers. 

Packetnet System Interface (PSI): The name for the software 
product that allows DIGITAL operating systems to participate in a 
packet-switching environment. 

parameter: An entry in the volatile or permanent database for a 
network management component. 

path: The route a packet takes from source to destination. 

path cost: The sum of the circuit costs along a path between two 
nodes. 

path length: The number of hops along a path between two nodes; 
that is, the number of circuits a packet must travel along to reach its 
destination. 

permanent database: A file containing information about network 
management components. 

permanent virtual circuit (PVC): A permanent logical association 
between two DTEs which is analogous to a leased line. Packets are 
routed directly by the network from one DTE to the other. 

physical address: The unique address value associated with a 
given system on an Ethernet circuit. An Ethernet physical address 
is defined to be distinct from all other physical addresses on an 
Ethernet. 
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point-to-point circuit: A circuit that connects two nodes, operating 
over a single line. 

polling: The activity that the control station performs with a 

multipoint circuit's tributaries to grant the tributaries permission to 
transmit. 

privileged: In DECnet-VAX terminology, this term means any user 
privileges in addition to NETMBX and TMPMBX. 

protocol: An agreed set of rules governing the operation of a 
communications link. 

proxy login: The procedure that permits a remote user to access a 
specific account at the local node, without supplying the user name 
and password. 

reachable node: A node to which the local node has a usable 
communications path. 

remote DTE: Any DTE in a network other than the one at which the 
user is located. 

remote node: To any one node in the network, this node is any other 
network node. 

router: A node that can send and receive packets, and route packets 
from one node to another. 

routing: The network function that determines the path along which 
data travels to its destination. 

routing node: A router. 

sink node: A node where logging sink types, such as a file or console, 
are actually located. 

source task: The task that initiates a logical link connection request 
in a task-to-task communication environment. 

state: The functions that are currently valid for a given component. 
States include line, circuit, local node, module, DTE, and logging. 

status: A display type for the SHOW and LIST commands. Status 
refers to dynamic information about a component that is kept in 
either the volatile or permanent database. 
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substate: An intermediate circuit state that is displayed for a circuit 
state display via the SHOW or LIST command. 

summary: The default display type for the SHOW and LIST 

commands. A summary includes the most useful information for a 
component, selected from the status and characteristics information. 

switched virtual circuit (SVC): A temporary logical association 
between two DTEs connected to a PSDN, which is analogous to 
connection by a dialup line. An SVC is set up only when there is 
data to transmit and is cleared when the data transfer is complete. 

synchronous disconnect: The disconnect that occurs when a 

nontransparent task can issue a call to terminate I/O operations over 
a logical link without deassigning the channel. Thus, the task can 
use the channel for subsequent I/O operations with the same or a 
different remote task. 

synchronous transmission: A mode of data transmission in which 
the time of occurrence of each signal representing a bit is related to a 
fixed time frame. 

target node: The node that receives a memory image during a 
downline load; a node that loops back a test message. 

target task: The task that receives and processes a logical link 
connection request in a task-to-task communication environment. 

task: In this manual, the term refers to an image running in the 
context of a process. 

task specifier: Information provided to DECnet-VAX software so 
that it can complete a logical link connection to a remote task. This 
information includes the name of the remote node on which the 
target task runs and the name of the task itself. 

terminal emulator: A program that acts as a transparent interface 
between two ports, making it appear as though a terminal on the 
local processor is directly connected to a remote processor. 

tributary: A physical termination on a multipoint circuit that is not a 
control station. 

tributary address: A numeric address that the control station uses to 
poll a tributary. 
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upline dump: A DECnet-VAX function that allows an adjacent 
unattended node to dump its memory to a file on a VAX/VMS 
system. 

virtual circuit: An association between two nodes (or two DTEs 
connected to a PSDN) whereby the two nodes (or DTEs) are able 
to interact as if a specific circuit were dedicated to them throughout 
the transmission. In reality a logical connection is established, the 
actual physical circuits being allocated according to route availability, 
overload conditions, and so on. 

virtual terminal: A pseudo device which connects a process to a 
physical terminal device. The virtual terminal can be disconnected 
from the physical terminal and reconnected later. 

volatile database: A memory image that contains information about 
network management components. 

window: A range of packets authorized for transmission across 
an X.25 DTE/DCE interface. The lowest sequence number in the 
window is referred to as the lower window edge (0 when the virtual 
circuit is just established). The packet send sequence number of the 
first data packet not authorized to cross the interface is the value of 
the upper window edge (that is, the lower window edge plus the 
window size). 

X.3: A CCITT recommendation that specifies the packet 

assembly/disassembly (PAD) facility in a public data network. 

X.25: A CCITT recommendation that specifies the interface between 
data terminal equipment and data circuit-terminating equipment for 
equipment operating in the packet mode on public data networks. 

X.28: A CCITT recommendation that specifies the DTE/DCE interface 
for a start-stop mode DTE accessing the packet 
assembly/disassembly (PAD) facility in a public data network 
situated in the same country. 

X.29: A CCITT recommendation that specifies procedures for 
the exchange of control information and user data between a 
packet-mode DTE and a packet assembly/disassembly (PAD) facility. 

X.29 terminal: A terminal connected to a packet assembly 
/disassembly (PAD) facility. 
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Area leakage problem* A-19 
AREA MAXIMUM COST parameter* 
3-94 
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See Level 2 router 
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Call 
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CALL TIMER parameter*3-44 
CALL VALUE parameter 

for incoming X.25 calls *3-108 


Index—2 








Index 


SCANCEL* 8-42 
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Collision Detect 
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DDCMP* 1-11, 2-7, 3-51 
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DLM* 1-2, 2-14, 3-51, 3-67 
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Ethernet* 1-8, 2-7, 3-50, 3-51 
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Command (cont'd.) 

NCP keywords *3-4 
remote execution of • 3-7 
syntax* 3-6 
Command node *4-2 
Command procedure*8-5, 8-56 

example for task-to-task operations* 
8-56 

for object *3-102 
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X.25 protocol module entry *2-5 
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4-30 
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of logical link activity • 2-38, 3-98 
of tributaries • 3-58 
station* 1-10, 2-10 
Controller loopback test *7-9, 7-11 
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COPY KNOWN NODES command* 

3-27 

examples *3-32 
FROM parameter *3-28 
TO qualifier*3-29 
USING qualifier *3-29 
WITH CLEAR qualifier*3-29 
WITH PURGE qualifier *3-29 
Copying 

node database* 1-24, 2-4, 3-27 
Cost 

circuit* 3-91 
control for circuit *2-35 
determining for circuit *3-91 
for routing • 2-34 
COST parameter 
for circuit *3-91 
Counter timer *3-36 
COUNTER TIMER parameter 
for circuit *3-71 
for executor*3-36 
for node *3-36 
Counters 

circuit • 3-71 
line *3-86 
logging • 3-36 
node *3-36 

X.25 protocol module*3-47 
zeroing • 3-36 

COUNTERS display type *3-127 
CPU (central processing unit) 

identification for downline load* 

4-17 

time requirements*5-45 
SCREMBX • 8-35 
CSMA/CD* 1-8, 1-9 
CUG (closed user group) *2-6, 3-40, 
3-107 


D 


$DASSGN«8-18, 8-25, 8-31, 8-55 
format* 8-31 

Data circuit-terminating equipment 
See DCE 

Data link control *2-4, 3-23 


Data link mapping 
see DLM 

Data network* 1-2 
Data terminal equipment 
See DTE 
Database 
circuit *3-2 

clearing or purging before copying 
node entries*3-30 
configuration* 1-22, 2-1, 3-2 
copying node* 1-24, 2-4, 3-27 
DECnet-VAX* 1-24 
line* 3-2 
logging *3-2 
module *3-2, 3-4 
node *3-2 
object *3-2, 3-4 
permanent* 1-22, 3-3 
VAX PSI* 1-22, 3-4 
volatile* 1-22, 3-3 
Datagrams 
Ethernet* 1-8 

DCE (data circuit-terminating 
equipment) *1-17 
DCL commands* 1-30 
DDCMP (DIGITAL Data Communica¬ 
tions Message Protocol)* 1-5 
asynchronous* 1-5, 1-10, 2-9, 

2- 16, 3-48 

asynchronous line* 1-6, 3-73 
circuit*2-7, 3-47, 3-51 
configuration* 1-10 
CONTROL line *3-74 
DMC line *3-74 

dynamic asynchronous network 
configuration • 5-25 
line*2-15, 3-75 
MOP *4-19 
multipoint* 1-10 

multipoint network configuration* 

5-20 

multipoint tributary addressing* 

3- 49 

POINT line *3-74 
point-to-point* 1-10 
point-to-point addressing • 3-48 
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DDCMP (DIGITAL Data Communica¬ 
tions Message Protocol) (cont'd.) 
protocol* 1-11 

static asynchronous network 
configuration • 5-23 
synchronous* 1-5, 1-10, 2-8, 2-16 
synchronous devices* 1-12 
synchronous line* 1-6 
synchronous point-to-point network 
configuration *5-17 
TRIBUTARY line *3-74 
DEAD THRESHOLD parameter • 3-58 
Dead timer *3-81 
DECnet-VAX 

configuration database* 1-20 
configuration on a VAX/VMS 
system • 1 -2 

configuration on a MicroVMS 
system* 1-2 

configuration prerequisites • 5-1 
functions* 1-4 
host services* 1-4, 1-20 
over terminal lines *5-11 
over the Cl *5-10 
software • 1 -22 

DECnet-VAX license* 1-21, 2-28 
end node kit* 1-21, 6-1 
full function kit* 1-21, 6-1 
installing the key* 1-21, 5-8, 6-1 
DECS A (DIGITAL Ethernet Communica¬ 
tions Server) 

connection to remote console *4-29 
DEFAULT ACCESS parameter*3-122 
SET EXECUTOR command *2-55 
DEFAULT DATA parameter 
for X.25 circuit *3-43 
Default DECnet account *5-1 

creation by NETCONFIG.COM • 5-1, 
5-6 

example* 5-1 

use in access control • 2-53, 3-121 
DEFAULT PROXY parameter • 3-124 
SET EXECUTOR command *2-57 
DEFAULT WINDOW parameter 
for X.25 circuit *3-43 


DEFINE EXECUTOR command 
TYPE parameter *3-87 
DEFINE NODE command *5-6 
Delay timer*3-81 
DEQNA 
See QNA 

DEQNA communications controller* 
1-8, 2-23, 3-14 
Designated router 
See Ethernet 
Destination 

of X.25 call *2-44 
DESTINATION qualifier*3-106 
DETACH privilege*5-3 
DEUNA 
See UNA 

DEUNA communications controller* 

1- 8, 2-23, 3-14 
Device 

CI-750*2-11, 2-16 
CI-780* 2-11, 2-16 
DHU11 asynchronous *2-9, 2-16 
DHV11 asynchronous *2-9, 2-16 
DMC11*1-12, 2-8, 2-16 
DMF32* 1-12, 2-8, 2-16 
DMF32 asynchronous *2-9, 2-16 
DMP11*1-12, 2-8, 2-16 
DMR11*1-12, 2-8, 2-16 
DM V11*2-8 

DMZ32 asynchronous *2-9, 2-16 
DPV11*2-24 
DUP11-DA *2-24 
DZ 11*1-12 

DZ11 asynchronous *2-9, 2-16 

DZ32 asynchronous *2-9, 2-16 

DZV11 asynchronous *2-9, 2-16 

KMS11-BD* 2-24 

KMS11-PX • 2-24 

KMS11-PY • 2-24 

KMY • 2-24 

QNA *2-12, 2-23 

UNA *2-12, 2-23 

DHU11 asynchronous device *2-9, 

2- 16 

DHV11 asynchronous device *2-9, 
2-16 
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DIAGNOSE privilege*5-4 
Dialup line*5-11 
DIGITAL Network Architecture 
See DNA 

DIOLM quota • 5-43 
Disconnect* 8-18 
abort *8-19, 8-41 
synchronous* 8-18 
DISCONNECT LINK command • 3-97 
Display type 

CHARACTERISTICS *3-126 
COUNTERS *3-127 
EVENTS *3-127 
STATUS *3-126 
SUMMARY • 3-126 
DLM (data link mapping)* 1-2, 1-3, 

1-18 

circuit* 1-2, 2-7, 2-14, 3-51 
CIRCUIT parameters *3-67 
incoming and outgoing calls *3-67 
network configuration • 5-29 
OWNER EXECUTOR circuit 
parameter *3-67 
setting up a circuit *3-70 
subaddresses • 3-69 
DMC11 device* 1-12, 2-8, 2-16 
DMF32 asynchronous device *2-9, 

2-16 

DMF32 device* 1-12, 2-8, 2-16 
DMP11 device* 1-12, 2-8, 2-16 
DMR11 device* 1-12, 2-8, 2-16 
DM V11 device *2-8 
DMZ32 asynchronous device *2-9, 
2-16 

DNA (DIGITAL Network Architecture) 
layers* 1-5 
protocols* 1-5 
Downline system load 
default loader files *4-17 
definition *4-1 
load requirements *4-6 
load sequence *4-6 
network example *5-19 
operator-initiated *4-2, 4-7 
over DDCMP circuit *4-8 
over Ethernet *4-3, 4-8 


Downline system load (cont'd.) 
target-initiated • 4-2 
unattended systems *4-1 
Downline task load *4-22 
DPV11 device *2-24 
DTE (data terminal equipment)* 1-17, 
2-5 

address *2-5 
bringing up *6-3 

configuration* 1-22, 1-25, 2-5, 6-3 
definition *2-1 

handling incoming calls *2-45 
handling outgoing calls *3-39 
subaddress *3-106 
DTE parameter 
for GROUP *3-41 
for PVC* 3-65 
DTE qualifier 

CHANNELS parameter • 3-39 
LINE parameter*3-39 
MAXIMUM CIRCUITS parameter* 

3-40 

SET MODULE X25-PROTOCOL 
command • 3-38 
STATE parameter *3-38 
DTR (DECnet Test Receiver) • 2-39 
DUMP ADDRESS parameter • 4-19 
Dump assistance multicast address* 

4-19 

DUMP COUNT parameter *4-19 
DUMP FILE parameter *4-20 
Dumping unattended system memory* 
4-19 

DUP1 1-DA device *2-24 
Duplex mode *3-80 
DUPLEX parameter *3-80 
DYING BASE parameter • 3-59 
DYING INCREMENT parameter • 3-60 
DYING THRESHOLD parameter*3-58 
Dynamic allocation of map registers 
and device drivers *5-46 
Dynamic asynchronous circuit *2-9 
VERIFICATION INBOUND parameter* 
3-58, 3-119 

Dynamic asynchronous connection* 

1-5, 1-10 
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Dynamic asynchronous connection 
(cont'd.) 

network configuration • 5-25 
password • 2-48 
reasons for failure *5-16 
Dynamic asynchronous line* 1-13, 
2-19, 5-11 

HANGUP parameter *3-82 
installing *5-14 
LINE SPEED parameter *3-82 
shutting down *5-16 
SWITCH parameter*3-82 
Dynamic switching 

manual switching of line *2-22 
procedure for line *2-19 
setting up lines *5-14 
DYNSWITCH • 2-21 
installing *5-14 

DZ11 asynchronous device *2-9, 2-16 
DZ11 device* 1-12 

DZ32 asynchronous device *2-9, 2-16 
DZV11 asynchronous device *2-9, 
2-16 


E 


End node* 1-2, 1-21 

caching on Ethernet • 2-33 
configuration • 2-29 
DECnet-VAX license kit* 1-21, 6-1 
definition *2-25 
Ethernet* 1-10, 2-32 
non-Ethernet* 1-10 
on VAXcluster* 1-16 
Phase IV *2-27 
ENQLM quota *5-43 
Error messages 
HLD • 4-26 

loopback testing *7-10 
Error reporting • 8-26, 8-42 

system service status *8-26, 8-42 
Ethernet* 1-6 

address conversion *3-89 
address format *3-14 
adjacent node *2-7 
area number in address *3-15 


Ethernet (cont'd.) 

area routing on *2-33, A-21 
broadcast address* 1-9, 2-3 
broadcast routing timer *3-95 
cable* 1-8 
carrier sense* 1-9 
characteristics* 1-8 
circuit* 1-5, 1-8, 2-7, 3-51 
circuit device* 1-8, 2-12 
circuit identification *3-50 
circuit parameters *3-61 
configuration* 1-5, 1-6 
configurator module* 1-22, 1-25, 

2-13, 3-62 

data link for VAXcluster* 1-15 
data rate • 1 -8 
datagrams* 1-8 
designated router* 1-10, 2-26, 

2- 32, 3-61 

determining physical address *3-16 
displaying physical address *3-16 
downline system load *4-8 
dump assistance multicast address* 

4-19 

end node* 1-10, 2-32, 3-61 
end node caching *2-33 
hardware address • 2-23, 3-14, 

3- 83, 7-14 

limiting end nodes *3-90 
limiting routers *3-89 
line *2-15 
line device*2-23 
line parameters *3-83 
line protocol *3-74 
multiaccess* 1-8 
multicast address* 1-9, 2-3 
multicast address definition • 3-16 
multicast address values *3-17 
network configuration • 5-28 
node* 1-8 

node address *2-3, 3-13 
node number in address *3-15 
non-DECnet application* A-13 
packets* 1-9 

physical address* 1-9, 2-3, 2-7, 

2-23, 3-14, 4-8, 7-14 
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Ethernet (cont'd.) 

physical address definition • 3-16 
physical address values*3-17 
protocol* 1-6, 2-7 
resetting physical address *3-15 
router* 1-10, 2-32, 3-61 
service operations • 3-55 
specification* 1-6 
topology* 1-8 
upline memory dump *4-20 
Ethernet loopback test *7-13 
to remote system *7-14 
UNA device*7-13 
Event 

class*3-115 
definition *2-46 
identification *3-115 
identifying location of*3-117 
list *2-46 
sink-related *2-47 
source *3-116 
source-related • 2-47 
type *3-115 
Event logger 
See EVL 

Event logging example *3-118 
EVENTS display type *3-127 
EVL (event logger)* 1-22, 2-39, 2-47 
Executor node *2-2, 4-2 
commands* 3-7 

F 


FAL (file access listener)* 1-22, 2-39 
File 

default access control* 1-34 
logical name in specification* 1-37 
manipulation over the network* 1-29 
specification* 1-31 
specification access control string • 
1-34 

specification over the network* 1-34 
File access 

over network* 1-4 
remote* 1-29 
File access listener 


See FAL 
FILE parameter 

for DECnet-VAX command 
procedure *3-103 
FILLM quota *5-43 
Frame control 
X.25 lines *3-84 
FROM parameter 

COPY KNOWN NODES command* 
3-28 


G 


Gateway node 
See X.25 
$GETDVI • 8-43 
GROUP parameter 

for X25-SERVER module *3-107 
GROUP qualifier 

DTE parameter*3-41 
for X25-PROTOCOL module *3-41 
NUMBER parameter*3-41 
TYPE parameter *3-41 
Guidelines 

system configuration • 5-40 to 5-48 

H 


HANGUP parameter *3-82 
Hardware address 
Ethernet *3-14 

HARDWARE ADDRESS parameter 
SET NODE command *4-12 
Hardware loopback device *7-9 
Hello timer*3-56 
HELP parameter 

LOOP CIRCUIT command *7-16 
Heterogeneous command terminal* 

1-4, 1-29 

Heterogeneous network 
remote file operations • 9-1 
Higher-level language statements* 1-30 
HLD (host loader)* 1-22, 2-39, 4-22 
mapping table *4-25 
HLDTB$ • 4-25 
HNODE$ • 4-25 


Index—9 












Index 


Hop* 2-34 
Host identification 

for downline task load *4-14 
Host loader 
See HLD 
Host node 

for X.25 connection* 1-4, 3-109, 
3-111 
Host services 

DECnet-VAX* 1-4, 1-20, 4-1 
on Ethernet *2-3 
HTASK$ • 4-25 


I 


IAS node *9-3 
Identification 

of circuits *3-47 
of events *3-115 
of lines *3-72 
of node address *2-3, 3-9 
of node name *2-3, 3-9 
of objects *3-101 
of X.25 connector node *3-112 
IDENTIFICATION parameter 
for local node *3-11 
INACTIVE BASE parameter*3-59 
INACTIVE INCREMENT parameter* 
3-60 

INACTIVE THRESHOLD parameter* 
3-58 

INACTIVITY TIMER parameter*3-99 
Inbound logical link connection* 1-35 
INBOUND parameter 

SET NODE command *3-123 
Incoming calls to a DTE *2-45 
INCOMING TIMER parameter • 3-98 
Initialization 

of DDCMP node* 1-11 
of Ethernet node* 1-8 
of Phase III node *2-49, A-20 
Installation 
network* 6-1 
VAX PSI • 6-3 

IRPCOUNT parameter* 5-40 


K 


Key 

DECnet-VAX license* 1-21, 2-28 
KMS-11 

dumping microcode*7-20 
KMS-11 DUMP Analyzer (see PSIKDA) 
KMS11-BD device *2-24 
KMS11-PX device *2-24 
KMS11-PY device *2-24 
KMY interface *2-24 
KNOWN keyword *3-127 

L 


LAN (local area network) 

Ethernet • 1 -5 
LAPB line 

See X.25 line 

LCN (logical channel number) *3-39 
LEF (local event flag wait) state • 8-24 
Level 1 router* 1-2, 2-25, 2-27, A-1 
Level 2 router* 1-2, 2-25, 2-27, A-1 
subnetwork* A-3 

LIB$ASN_WTH_MBX *8-17, 8-35 
License 

See DECnet-VAX license 
Line* 1-1 

asynchronous DDCMP devices* 
2-16 

buffer size *3-78 

buffers for DDCMP line *3-80 

Cl • 2-15 

commands *3-72 
counters* 3-86 
database* 3-2 
DDCMP *2-15 
definition* 2-14 
device name *3-72 
dialup* 5-11 

dynamic asynchronous* 1-13, 2-19, 
5-11 

dynamic switching • 2-19 
Ethernet *2-15, 3-83 
identification *3-72 
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Line (cont'd.) 

installing dynamic asynchronous* 
5-14 

installing static asynchronous*5-11 

LAPB • 3-74 

multipoint • 2-17 

name *2-15 

operational state *3-78 

parameters *3-75 

point-to-point *2-17 

protocol *3-73 

state *2-15 

static asynchronous* 1-13, 2-18, 
5-11 

synchronous DDCMP devices *2-16 

terminal *1-13 

timers* 3-80 

types *3-75 

X.25*2-15 

LINE BUFFER SIZE parameter• 3-23, 
3-78 

LINE parameter 
for DTE *3-39 

LINE SPEED parameter*3-82 
Link 

See Logical link 
LIST command *3-125 
Load assistance multicast address *4-4 
Load file identification for downline 
load *4-14 

LOAD NODE command *4-2, 4-11 
HOST parameter *4-14 
overriding default parameters *4-12 
SECONDARY LOADER parameter* 
4-17 

SERVICE DEVICE parameter *4-17 
SERVICE PASSWORD parameter* 
4-18 

SOFTWARE IDENTIFICATION 
parameter *4-17 

SOFTWARE TYPE parameter *4-16 
TERTIARY LOADER parameter* 
4-13 

LOAD VIA command *4-11 

PHYSICAL ADDRESS parameter* 
4-11, 4-18 


LOAD VIA command (cont'd.) 

SERVICE DEVICE parameter *4-17 
Local area network 
See LAN 

Local loopback test *7-8 
Local node* 1-20, 1-29, 2-2, 3-7 
operational state *3-27 
restrictions • 6-4 
setting address *3-10 
states • 6-4 

Local-to-local loopback test *7-6 
Local-to-remote loopback test *7-5 
Logging* 1-25, 2-46 
commands *3-113 
console*2-47, 3-113 
database* 3-2 
file*2-47, 3-113 
monitor*2-47, 3-113 
parameters *3-113 
sink*2-47, 3-113 
state *3-117 
Logical channel number 
See LCN 

Logical link* 1-1, 1-25, 8-11,8-13, 
8-14, 8-18, 8-24 
aborting *8-14, 8-41, 8-42 
access control information* 1-35 
assigning channel for *8-24, 8-43 
commands *3-97 
completing connection of *8-15, 
8-25, 8-38, 8-46 
control *2-37 
controlling activity • 3-98 
default access control information • 
1-35 

definition • 2-37 

disconnecting*2-37, 3-97, 8-14, 
8-18, 8-41, 8-51 
handshaking sequence • 8-14 
inactivity timer *2-38 
inbound* 1-35, 3-97 
incoming timer *2-38 
maximum number of*2-37, 3-97 
outbound* 1-35, 3-97 
outgoing timer*2-38 
parameters* 2-37 


Index—11 









Index 


Logical link (cont'd.) 

protocol operation • 2-38 
protocol parameters*3-98 
rejecting a request *8-48 
requests • 8-11, 8-13, 8-15, 8-24, 
8-36, 8-38, 8-44 
retransmission delay *2-38 
retransmission time *2-38 
SYS$NET *8-16 
terminating • 8-14, 8-18, 8-25, 

8-31, 8-42 
timers *3-98 
Logical name 

as device name* 1-37 
as node name* 1-37 
in process logical name table* 1-37 
translation • 1-37 
use in network application* 1-37 
LOGINOUT image *2-51, 2-53 
LOOP CIRCUIT command *7-9 

ASSISTANT NODE parameter*7-16 
ASSISTANT PHYSICAL ADDRESS 
parameter* 7-16 
HELP parameter*7-17 
NODE parameter *7-15 
PHYSICAL ADDRESS parameter* 
7-14 

LOOP EXECUTOR command *7-8 
LOOP LINE command 

COUNT parameter* 7-19 
LENGTH parameter *7-19 
WITH parameter*7-19 
LOOP NODE command *7-2 
CIRCUIT parameter *7-4 
Loop node name *7-4 
Loopback 

assistance* 7-16 
connector* 7-9 
Loopback mirror *7-2 
Loopback test 
circuit • 7-9 
circuit-level *7-1 
controller*7-9, 7-11 
local node*7-8 
local-to-local • 7-6 
local-to-remote • 7-5 


Loopback test (cont'd.) 
node-level* 7-2 
over Ethernet circuit *7-14 
software* 7-9, 7-10 
to a remote node *7-3 
using a loop node name *7-4 
X.25 line-level *7-17 
LRPCOUNT parameter *5-40 
LRPSIZE parameter*5-40 


M 


MACRO programs 

in network application* 1-30 
MAIL object *2-39 
Mailbox *8-10, 8-34, 8-35 
creation of 

(SCREMBX) • 8-35 
message format *8-35 
Maintenance operation protocol 
See MOP 

Maintenance operations over the 
network *4-1 

MAXIMUM ADDRESS parameter • 3-11 
MAXIMUM AREA parameter • 3-90 
MAXIMUM BLOCK parameter 
for X.25 line *3-85 
MAXIMUM BROADCAST NON¬ 
ROUTERS parameter 
for Ethernet circuits *3-90 
MAXIMUM BROADCAST ROUTERS 
parameter 

for Ethernet circuits*3-90 
Maximum buffers 
for executor *3-26 

MAXIMUM BUFFERS parameter*3-26, 
3-60 

MAXIMUM CIRCUITS parameter 
for DTE • 3-40 
for executor node *3-26 
for X.25 server module *3-110 
MAXIMUM CLEARS parameter • 3-44 
MAXIMUM COST parameter • 3-93 
MAXIMUM DATA parameter 
for PVC • 3-66 
for X.25 lines *3-84 
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MAXIMUM DATA parameter (cont'd.) 

for X.25 virtual circuit*3-43 
MAXIMUM HOPS parameter*3-93 
MAXIMUM LINKS parameter • 3-97 
MAXIMUM RECALLS parameter • 3-68 
MAXIMUM RESETS parameter • 3-45 
MAXIMUM RESTARTS parameter* 
3-46 

MAXIMUM RETRANSMIT parameter* 
3-84 

MAXIMUM ROUTERS parameter*3-62 
for an Ethernet circuit *3-89 
MAXIMUM TRANSMITS parameter* 
3-60 

Maximum visits *2-35 
MAXIMUM VISITS parameter • 3-94 
MAXIMUM WINDOW parameter 
for PVC • 3-66 
for SVC *3-43 
for X.25 line*3-85 
Memory pool *5-40 
Memory requirements 
normal* 5-40 
worst-case • 5-43 
Message *8-10, 8-17, 8-28, 8-30 
data *8-17 

exchanging • 8-17, 8-25, 8-41 
interrupt • 8-10, 8-41 
mailbox *8-10, 8-17 
network status *8-10 
optional user data*8-10, 8-15, 8-32 
Microcode* 1-12 

dumping KMS-11 • 7-20 
MICROCODE DUMP parameter • 7-20 
MicroVMS system 

as DECnet—VAX node* 1-2, 5-5 
MIRROR (loopback mirror)* 1-22, 2-39 
Mixed Phase Ill/Phase IV network* 

A-15 

Modem *5-12, 7-9 
Module* 1-25 
database *3-2 

Ethernet configurator* 1-25, 2-13, 
3-62 

X.25 access* 1-25, 2-46, 3-111 
X.25 protocol* 1-25, 3-37 


Module (cont'd.) 

X.25 server* 1-25, 2-43, 3-105 
X.25 trace* 1-25 
X.29 server* 1-25, 2-43, 3-105 
MOM subprocess of NML*4-2 
Monitor Utility (MONITOR) • 5-44 
MOP (maintenance operation protocol)* 
4-2, 4-19 
error recovery *4-7 
request memory dump message* 
4-19 
Multiaccess 
circuit • 2-7 
Ethernet* 1-8, 1-9 
Multicast address* 1-8, 1-9 
broadcast • 3-17 
dump assistance *4-19 
Ethernet* 3-16 
group* 3-17 
load assistance *4-4 
Multihost connector node 
See X.25 

Multiple inbound connects • 8-10, 8-40, 
8-53 

Multiple-area network* 1-3 
conversion to* A-11 
design of • A-3 

example of configuration • A-8 
example of design • A-6 
Multipoint 
circuit • 2-10 

configuration* 1-5, 1-10, 5-20 

control circuit • 2-7 

control station *2-10 

line* 2-17 

polling *2-10 

tributary *2-10 

tributary address*2-10, 3-49 

tributary circuit *2-7 

N 


NAME parameter 

identifying logging device *3-114 
SET NODE command *3-10 
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NCB (network connect block) • 3-102, 
8-14, 8-37 

destination descriptor*8-38 
for incoming X.25 call *2-45 
NCP* 1-19, 1-22 

command functions*3-4 
command keywords *3-4 
command syntax *3-6 
commands* 1-20 
definition *3-4 

invalid grouping error message* 
3-22 

LIST command *3-125 
SHOW command *3-125 
specifying plural components *3-6, 
3-127 

tailoring the configuration database* 
5-10 

TELL prefix *3-9 
users* 1-19 
using commands *3-1 
_NET: • 8-34, 8-44 
NETACP (network ancillary control 
program)* 1-22, 5-46 
NETCONFIG.COM* 1-24, 3-3, 5-6 to 
5-9 

creation of default DECnet account* 
5-1 

supplying node address *5-6 
NETDRIVER (network driver)* 1-22, 
5-45 

NETMBX privilege *2-52, 5-3 
NETSERVER 

See Network server process 
NETSERVER.LOG • 4-26 
NETSERVER$TIMEOUT • 2-41 
NETUAF.DAT*2-51, 2-57 
Network 

access control *2-48 
access levels* 1-30 
bringing up *6-1 
configuration* 1-5, 5-1 
conversion to multiple-area network 
• A-11 

CPU time requirements*5-45 
decentralized* 1-3 


Network (cont'd.) 
example* 1-25 

limiting number of areas *3-90 

monitoring *3-125 

multinode* 1-3 

multiple-area* 1-3 

multiple-area configuration • A-3 

normal memory requirements*5-40 

object • 3-2 

passwords *2-53 

restrictions on mixed •2-21, A-16 

security • 2-53 

shutting down • 6-3 

terminal *3-114 

testing* 7-1 

to display network *8-2 
topology* 1-25 
user interface to* 1-28 
user operations* 1-29, 8-1 
worst-case memory requirements* 
5-43 

Network configuration procedure *5-17 
to 5-39 

Network connect block 
See NCB 

Network Control Program 
See NCP 
Network driver 
See NETDRIVER 

Network Information and Control 
Exchange 
See NICE 
Network interface 
VAX/VMS* 1-3 
Network management 
functions* 1-4 
responsibilities* 1-20 
Network name, declaring • 8-39, 8-53 
NETWORK parameter 

for X.25 protocol module command 
•3-41 

Network process failures 
potential causes *2-42 
NETWORK qualifier 

for X.25 access module *3-111 
Network server process *2-41 
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Network Services Program 
See NSP 

Network task, declaring • 8-10, 8-16, 
8-39 

NICE (Network Information and Control 
Exchange)•3-4 

NICONFIG • 1-22 

NML (network management listener)* 

1-22, 2-39, 6-2 
access control *3-121 

Node* 1-1, 1-25, 3-9 

address *2-2, 2-30, 3-9, 3-88, 

A-16 

address conversion • 3-89 
addressing Cl node *3-49 
adjacent* 1-1, 2-26 
area number*2-2 
automatic configuration • 5-5 
bringing up DECnet-VAX node *6-1 
changing local address *3-13 
checking type* 1-14, 2-59, 3-123 
clearing or purging database before 
copying *3-30 
commands* 3-6 

configuring for DECnet-VAX* 1-24 
conversion of Phase IV address* 

2-30 

copying database* 1-24, 2-4, 3-27 
counters *3-36 
database *3-2 

default access account* 1-35 
definition • 2-1 
display of type *3-88 
end* 1-2, 2-25 
Ethernet address *2-3, 3-13 
executor*2-2, 3-7 
identification • 2-2, 2-3, 2-30, 3-9 
initialization request *3-57 
local* 1-20, 1-29, 2-2, 3-7 
logical name in file specification* 
1-37 

name*2-2, 3-9 
non-Ethernet* 1-10 
nonrouting • 2-26 
number *2-2, 2-30, 3-9 
number in Ethernet address *3-15 


Node (cont'd.) 

parameters*2-4, 3-18 
Phase 11*2-26 
Phase 111*2-26 
Phase IV *2-26 
reachable* 2-34 

remote* 1-20, 1-29, 2-2, 3-7, 3-57 
removing remote name and address 
•3-13 

routing* 1-2, 2-25, 2-26 
shutting down DECnet-VAX node* 
6-3 

specification access control string* 
1-34 

specification string for node* 1-34 
state*2-5, 3-27 
to display network *8-1 
type *2-26, 3-87 
X.25 connector* 1-4 
X.25 host* 1-4 
NODE parameter *7-15 

for X.25 host node *3-109 
identifying X.25 connector• 3-112 
Node-level access control *2-55 
Node-level loopback test *7-2 
logical link operation • 7-2 
over specific circuit* 7-2 
NODRIVER *2-18, 2-19, 5-5, 5-1 1 
Nonpaged dynamic memory pool *5-40 
Nonprivileged access control string* 
2-51 

Nonrouting node 
See End node 
Nontransparent 

communication* 1-33 
user network operations* 1-29 
Nonzero object *2-39 
NPAGEDYN parameter • 5-40 
NSP (Network Services Program) 
message retransmission • 2-38, 

3-99 

receive buffers *3-23 
NUMBER parameter 

for DECnet objects • 3-102 
for DLM circuit • 3-67, 3-68 
for DTE *3-107 
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NUMBER parameter (cont'd.) 
for GROUP*3-41 


o 


Object* 1-25 

access control • 2-40 
addressing *2-39 
command procedure for DECnet- 
VAX • 2-40, 3-102 
command procedure for PSI • 2-43 
commands*3-101 
database *3-2 
DECnet-VAX • 2-39 
definition • 2-38 
identification *3-101, 3-104 
name *2-39, 3-102 
network*2-38, 3-2 
nonzero*2-39, 3-102 
number *8-38, 8-53 
parameters* 3-101 
proxy login access *2-58 
PSI account information • 2-43 
TASK *2-39, 3-102 
type *2-38, 8-14 
type number*2-39, 3-102 
user-defined *2-38 
VAX PSI *2-39, 2-43, 3-104 
zero-numbered *2-39, 3-102 
OBJECT parameter *3-109 
OPCOM (Operator Communication 
Facility) *2-47, 3-114, 6-4 
OPER privilege*5-3 
Operational state 
of circuit *3-54 
of lines *3-78 

Operator Communication Facility 
See OPCOM 

Operator-initiated downline load *4-2, 
4-7 

Outbound logical link connection* 1-35 
Outgoing call 
from DTE *3-39 

OUTGOING TIMER parameter • 3-98 
Overlaying RSX-1 IS tasks*4-28 


OWNER EXECUTOR parameter 
for DLM circuit *3-67 

p 


P/OS node*9-6 

Packet assembly/disassembly facility 
See PAD 

Packet size parameters • 3-43 
Packet switching data network 
See PSDN 

PAD (packet assembly/disassembly 
facility)* 1-4, 3-108 
Partitioned area problem* A-14 
example of • A-14 
Password 

for dynamic connection *2-48, 2-59 
receive *2-49, 3-119 
routing initialization* 1-14, 2-27, 
2-48, 3-119, A-20 
transmit*2-49, 3-119 
Path *2-34 
cost • 2-34 
length *2-34 

Path control parameters • 3-92 
for areas • 3-94 

Permanent database* 1-22, 3-3 
copying node entries *3-29 
Permanent virtual circuit 
See PVC 

Phase II node *2-26 
Phase III node *2-26 

in Phase IV network* A-15 
restrictions* A-16 
Phase IV 

end node *2-27 
node* 2-26 
node address *2-30 
router *2-27 
PHONE object *2-39 
Physical address 

Ethernet* 1-9, 3-14, 3-16 
PHYSICAL ADDRESS parameter 
for LOOP CIRCUIT command *7-16 
for TRIGGER command *4-8 
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Pipeline quota *2-37, 3-100 
PIPELINE QUOTA parameter 

SET EXECUTOR command • 3-100 
Point-to-point 
circuit • 2-7 

configuration* 1-5, 1-10, 5-18 
DDCMP addressing • 3-48 
line *2-17 

security for connection • 2-59, 3- 
119 

Polling* 1-10, 2-10 

POLLING STATE parameter*3-59 

Primary loader *4-2 

PRIORITY parameter*3-109 

Privilege 

ACNT • 5-2 
BYPASS *5-2 
CMKRNL* 5-2 
DETACH *5-3 
DIAGNOSE *5-4 
for access control • 2-51 
for network operations*5-2 
NETMBX • 2-52, 5-3 
OPER • 5-3 

required for NCP commands*2-53 
SYSNAM • 5-3 
SYSPRV • 5-3 
TMPMBX • 2-52, 5-2 
to configure network *5-1 
to issue CLEAR ALL or PURGE 
command *2-53 
to issue SET ALL or DEFINE 
command • 2-53 
to modify permanent database* 
2-53 

to modify volatile database • 2-53 
to start the network *2-53 
Program load request *4-4 
over Ethernet *4-4 
Programming language 

in network application* 1-30 
selecting for network operation • 
1-31 

Protocol module 
See X.25 

PROTOCOL parameter*3-73 


Protocols* 1-5 
Proxy 

access* 2-56 

access display for executor*3-124 
access display for object *3-125 
access file specification *3-124 
account• 2-56 
login • 2-56 
Proxy login 

access control* 1-35, 2-56 
access control commands *3-124 
account *2-56 
control *2-57 

DEFAULT PROXY parameter*2-57 
enabling access *2-57 
NETUAF.DAT *2-57 
PROXY parameter *2-58 
PROXY parameter*3-124 

SET OBJECT command *2-58 
PSDN (packet switching data network) • 

1- 2, 1-3, 1-6, 1-17, 2-5 
identification *3-41, 3-111 
installation • 6-3 

PSI ancillary control process 
See PSIACP 

PSIACP (PSI ancillary control process)* 
1-22 
PSIKDA 

KMS-11 Dump Analyzer *7-21 
PSIXTA 

X.25 Trace Analyzer*7-20 
PURGE EXECUTOR command *3-22 
PVC (permanent virtual circuit)* 1-17, 

2- 8, 2-14 
parameters • 3-65 

Q 


$QIO 

format • 8-44, 8-46, 8-48, 8-50, 
8-51, 8-52, 8-53 
IO$_ACCESS • 8-36, 8-40, 8-44, 
8-46 

IO$_ACCESS!IO$M_ABORT • 8-40, 
8-48 

IO$_ACPCONTROL • 8-40, 8-53 
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$QIO (corn'd.) 

IO$_DE ACCESS! IO$M_ABORT • 
8-42, 8-52 

IO$_DEACCESS!IO$M_SYNCH • 
8-51 

IO$_READVBLK • 8-50 
IO$_WRITE VBLK • 8-49 
IO$_WRITEVBLK1 IO$M_ 
INTERRUPT • 8-41, 8-50 
$QIO(IO$_ACCESS!IO$M_ABORT) • 
8-40 

format* 8-48 

$QIO(IO$_ACCESS) • 8-36, 8-40 
format *8-44, 8-46 
$QIO(IO$_ACPCONTROL) • 8-40 
format *8-53 

$QIO(IO$_DE ACCESS! IO$M_ABORT) • 
8-42 

format* 8-52 

$QIO(IO$_DEACCESS!IO$M_SYNCH) 
format* 8-51 

$QIO(IO$_READVBLK) • 8-50 
format • 8-30 

$QIO(IO$_WRITEVBLK! IO$M_ 
INTERRUPT 
format) • 8-50 

$QIO(IO$_WRITEVBLK) • 8-49 
format • 8-28 
QNA 

Ethernet circuit device *2-12 
Ethernet line device *2-23 
Quota 

pipeline*2-37, 3-100 

R 


RCF (remote console facility) 
error messages *4-30 
invoking *4-29 
Reachable node *2-34 
RECALL TIMER parameter • 3-68 
Receive buffers *3-23 
RECEIVE BUFFERS parameter 
for DDCMP line *3-80 
for X.25 line*3-86 
Receive password • 2-49 


Remote command execution *3-7 
Remote console connection • 4-29 
Remote file access* 1-29, 8-1 
Remote file operations 

general DECnet-VAX restrictions* 
9-2 

heterogeneous network *9-1 
VAX/VMS to IAS *9-3 
VAX/VMS to P/OS *9-6 
VAX/VMS to RSTS/E • 9-8 
VAX/VMS to RSX (using FCS-based 
FAL) *9-15 

VAX/VMS to RSX (using RMS- 
based FAL) *9-12 
VAX/VMS to RT-11*9-18 
VAX/VMS to TOPS-10 • 9-23 
VAX/VMS to TOPS-20* 9-27 
VAX/VMS to VAX/VMS (previous 
DECnet release) • 9-32 
Remote node* 1-20, 1-29, 2-2, 3-7 
copying database*2-4, 3-27 
loopback test • 7-3 
setting name and address *3-10 
RESET TIMER parameter*3-45 
Responsibilities of system manager* 
1-20 

RESTART TIMER parameter*3-46 
Retransmit timer • 3-81 
formula for *3-81 
RMS calls* 1-30 
Route-through control • 3-94 
Router* 1-2, 1-21, 3-61, 6-1 
area* 1-2, 2-27 
definition *2-25 
designated* 1-10, 2-26, 2-32 
Ethernet* 1-10, 2-32 
level 1*1-2, 2-25, 2-27, A-1 
level 2*1-2, 2-25, 2-27, A-1 
on VAXcluster* 1-16 
Phase IV *2-27 

redundant level 2 routers *A-4 
ROUTER PRIORITY parameter*3-62 
Routing • 2-24 
area • 1-2 

broadcast message timer *2-37 
commands* 3-87 
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Routing (cont'd.) 
concepts* 2-34 

configuration considerations • 2-24 

control parameters *3-91 

cost *2-34 

definition of* 1-2 

hop *2-34 

initialization passwords*2-27, 2-48, 

2- 49, 2-59, 3-119, A-20 
maximum visits *2-35 
message*2-36, 3-95 
message timer*2-37 
parameters *2-34 

path *2-34 

path control parameters*3-92 
path cost *2-34 
path length *2-34 
reachable node *2-34 
route-through control parameters* 

3- 94 

segmented message *2-37 
setting configuration limits *3-89 
timer *3-95 

timing of messages*2-37 
verification • 3-56 

Routing initialization password* 1-14 
Routing node *2-25 
See Router 
Routing timer *2-37 
RSTS/E node *9-8 
RSX node *9-12, 9-15 
RSX-11S 

checkpointing tasks *4-28 
downline load of system *4-1 
NETGEN procedure *4-23 
overlaying tasks *4-28 
task load *4-22 
RT-11 node *9-18 


s 


Satellite Loader 
See SLD 

Scheduling timer *3-81 
Secondary loader*4-6, 4-13, 4-14 


SECONDARY LOADER parameter* 

4-17 

Security 

for dynamic asynchronous 
connection* 1-14 

for point-to-point connection • 2-59, 
3-119 

protecting network configuration 
files *2-53 

SEGMENT BUFFER SIZE parameter 
for executor*3-24 
Server module 

See X.25 server module and X.29 
server module 

Service 

circuit identification for downline 
load *4-18 

device identification for downline 
load *4-17 

operations for circuit *3-55 
password for downline load *4-18 
SERVICE CIRCUIT parameter • 4-8 
SERVICE DEVICE parameter *4-17 
Service timer *3-81 
SET CIRCUIT command 

CHANNEL parameter*3-65 
COST parameter *3-91 
COUNTER TIMER parameter • 3-71 
DTE parameter *3-65 
MAXIMUM BUFFERS parameter* 
3-60 

MAXIMUM DATA parameter • 3-66 
MAXIMUM RECALLS parameter* 
3-68 

MAXIMUM ROUTERS parameter* 
3-62, 3-89 

MAXIMUM TRANSMITS parameter* 
3-60 

MAXIMUM WINDOW parameter* 
3-66 

NUMBER parameter*3-67, 3-68 
OWNER EXECUTOR parameter* 
3-67 

polling control parameters • 3-58 
POLLING STATE parameter • 3-59 
RECALL TIMER parameter • 3-68 
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SET CIRCUIT command (cont'd.) 

ROUTER PRIORITY parameter • 3-62 
SERVICE parameter *3-55, 4-6, 

4-21 

STATE parameter*3-55, 4-21 
TRIBUTARY parameter*3-49 
TYPE parameter *3-65 
USAGE parameter*3-65, 3-69 
VERIFICATION INBOUND parameter* 
3-58, 3-119 

VERIFICATION parameter*3-56 
SET EXECUTOR command 

ADDRESS parameter*3-10, 3-88 
AREA MAXIMUM COST parameter* 
3-94 

AREA MAXIMUM HOPS parameter* 
3-94 

BROADCAST ROUTING TIMER 
parameter *3-95 

BUFFER SIZE parameter • 3-11, 3-23 
COUNTER TIMER parameter*3-36 
DEFAULT ACCESS parameter* 

2- 55, 3-122 

DEFAULT PROXY parameter• 2-57, 

3- 124 

DELAY FACTOR parameter • 3-99 
DELAY WEIGHT parameter*3-99 
IDENTIFICATION parameter*3-11 
INACTIVITY TIMER parameter*3-99 
INCOMING TIMER parameter • 3-98 
local node address *3-10 
MAXIMUM ADDRESS parameter* 
3-11 

MAXIMUM AREA parameter • 3-90 
MAXIMUM BROADCAST 

NONROUTERS parameter* 

3-90 

MAXIMUM BROADCAST ROUTERS 
parameter* 3-90 

MAXIMUM BUFFERS parameter* 
3-26 

MAXIMUM CIRCUITS parameter* 
3-26 

MAXIMUM COST parameter • 3-93 
MAXIMUM HOPS parameter • 3-93 
MAXIMUM LINKS parameter*3-97 


SET EXECUTOR command (cont'd.) 
MAXIMUM VISITS parameter • 3-94 
OUTGOING TIMER parameter*3-98 
PIPELINE QUOTA parameter*3-100 
RETRANSMIT FACTOR parameter* 
3-99 

ROUTING TIMER parameter • 3-95 
SEGMENT BUFFER SIZE parameter* 
3-24 

STATE parameter*3-27, 6-4 
SUB ADDRESSES parameter • 3-69 
SET EXECUTOR NODE command *3-7 
access control information *3-122 
SET HOST command 

heterogeneous command terminal* 
1-29, 8-3 

SET LINE command 

CONTROLLER parameter*7-18 
DUPLEX parameter *3-80 
LINE BUFFER SIZE parameter*3-23, 
3-78 

MAXIMUM BLOCK parameter*3-85 
MAXIMUM DATA parameter*3-84 
MAXIMUM RETRANSMIT parameter 
•3-84 

MAXIMUM WINDOW parameter* 

3- 85 

MICROCODE DUMP parameter* 7-20 
PROTOCOL parameter*3-73, 3-75 
RECEIVE BUFFERS parameter*3-80 
SERVICE TIMER parameter • 4-6, 

4- 22 

STATE parameter*3-78, 7-18 
SET LOGGING command • 3-125 
EVENTS parameter*3-115, 3-117 
NAME parameter *3-114 
STATE parameter *3-1 17 
SET LOGGING EVENTS command* 
3-113 

SET LOGGING MONITOR command 
SINK parameter *3-117 
SET LOGGING STATE command* 
3-113 

SET MODULE CONFIGURATOR 
command 

KNOWN CIRCUITS parameter*3-64 
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SET MODULE CONFIGURATOR 
command (cont'd.) 

STATUS display 3-64 
SURVEILLANCE DISABLED 
parameter* 3-64 

SURVEILLANCE ENABLED parameter 
•3-63 

SET MODULE X25-ACCESS command 
ACCOUNT parameter*3-112 
NETWORK qualifier*3-111 
NODE parameter *3-112 
PASSWORD parameter *3-112 
USER parameter*3-112 
SET MODULE X25-PROTOCOL 
command *3-37 
CALL TIMER parameter • 3-44 
CLEAR TIMER parameter*3-44 
DEFAULT DATA parameter*3-43 
DEFAULT WINDOW parameter* 
3-43 

DTE qualifier*3-38 
GROUP qualifier *3-40 
MAXIMUM CLEARS parameter* 
3-44 

MAXIMUM DATA parameter*3-43 
MAXIMUM RESETS parameter* 

3-45 

MAXIMUM RESTARTS parameter* 
3-46 

MAXIMUM WINDOW parameter* 
3-43 

NETWORK parameter *3-41 
RESET TIMER parameter • 3-45 
RESTART TIMER parameter • 3-46 
SET MODULE X25-SERVER command 
CALL MASK parameter • 3-108 
CALL VALUE parameter*3-108 
DESTINATION qualifier*3-106 
GROUP parameter*3-107 
MAXIMUM CIRCUITS parameter* 

3-110 

NODE parameter*3-109 
NUMBER parameter*3-107 
OBJECT parameter *3-109 
PRIORITY parameter*3-109 
STATE parameter*3-110 


SET MODULE X25-SERVER command 
(cont'd.) 

SUBADDRESSES parameter*3-106 
SET NODE command *7-5 

ACCESS parameter*2-55, 3-122 
ADDRESS parameter*3-5, 3-1 1 
COUNTER TIMER parameter*3-37 
DIAGNOSTIC FILE parameter • 4-18 
HARDWARE ADDRESS parameter* 
4-8, 4-11 

INBOUND parameter *3-123 
NAME parameter *3-10 
NONPRIVILEGED parameter • 3-12 1 
PRIVILEGED parameter *3-121 
RECEIVE PASSWORD parameter* 
3-119 

remote node name and address* 

3- 10 

SERVICE CIRCUIT command *4-7 
SERVICE CIRCUIT parameter • 4-11 
SERVICE DEVICE parameter • 4-17 
SERVICE PASSWORD parameter* 

4- 18 

SOFTWARE IDENTIFICATION 
parameter* 4-17 

SOFTWARE TYPE parameter*4-17 
TRANSMIT PASSWORD parameter* 
3-119 

SET OBJECT command 

ACCOUNT parameter *3-105 
FILE parameter*3-103, 3-104 
NUMBER parameter*3-102 
PASSWORD parameter*3-105, 
3-121 

PRIVILEGE parameter*3-121 
PROXY parameter*2-58, 3-124 
USER parameter*3-105, 3-121 
SHOW command • 3-125 
SHOW EXECUTOR CHARACTERISTICS 
command 

display of proxy access *3-124 
SHOW EXECUTOR command 

CHARACTERISTICS display *3-1 1 
display of Ethernet address *3-16 
display of executor type *3-88 
SHOW LINE command 
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SHOW LINE command (cont'd.) 
Ethernet hardware address*3-83, 
7-15 

SHOW MODULE CONFIGURATOR 
command • 3-63, 3-64 
SHOW NETWORK command *8-1, 8-4 
display of network status *8-1 
SHOW NODE command 

COUNTERS parameter*3-37 
display of node type *3-88 
Sink *2-47 

logging*2-47, 3-113 
name* 2-47 
node *2-47 
related event • 2-47 
state • 2-48 

SINK parameter *3-117 
Slave node *4-19 
SLD (Satellite Loader) *4-22 
building • 4-23 

SOFTWARE IDENTIFICATION 
parameter *4-17 

Software loopback test *7-9, 7-10 
Source task *8-14 
Source-related event • 2-47 
STARTNET.COM *5-6, 5-18, 6-3 
State 

logging *3-117 
of circuit *2-8 
of line *2-15 
of local node*2-5 
STATE parameter 
for circuit *3-55 
for DTE *3-38 
for executor node *3-27 
for line*3-78 

for X25-SERVER module *3-1 10 
Static asynchronous connection* 1-5, 

1-10, 1-13 

network configuration • 5-22 
reasons for failure *5-13 
Static asynchronous line* 1-13, 2-18, 
5-11 

installing *5-11 
shutting down *5-13 
STATUS display type *3-126 


Stream timer *3-81 
SUBADDRESSES parameter 

for SET EXECUTOR command *3-69 
for X25-SERVER module *3-106 
SUMMARY display type *3-126 
SVC (switched virtual circuit)* 1-17, 

2- 8, 2-14 

for DLM use *2-8, 2-14 
for X.25 native use *2-8 
SWITCH parameter *3-82 
Switched virtual circuit 
See SVC 

Synchronous connection 
multipoint* 1-5 
point-to-point* 1-5 

Synchronous disconnect • 8-14, 8-18, 
8-41, 8-51 
SYS$ASSIGN • 5-3 
SYS$CREMBX • 5-3 
SYS$CREPRC • 5-3 
SYS$LOGIN:NETSERVER.LOG *2-41, 

4- 26 

SYS$LOGIN:objectname.COM *3-102 
SYS$MANAGER:EVL.LOG *3-117 
SYSSMAN AGER:NET.LOG *3-128 
SYS$MANAGER:NETCONFIG.COM • 

5- 7 

SYS$MANAGER:RTTLOAD.COM • 6-2 
SYS$MANAGER:STARTNET.COM • 
5-8, 5-17, 6-2 

SYS$NET *8-16, 8-25, 8-39 
SYS$SYSTEM:NETNODE.DAT • A-11 
SYS$SYSTEM:objectname.COM • 

3- 102 

SYS$SYSTEM:SYSGEN 
See SYSGEN 

SYSSTRNLOG system service call* 
8-16 
SYSGEN 

IRPCOUNT parameter*5-42 
LRPCOUNT parameter*5-42 
LRPSIZE parameter*5-42 
NPAGEDYN parameter • 5-41 
running* 5-41 

updating parameters for DECnet* 
5-41 
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SYSNAM privilege*5-3, 8-40 
SYSPRV privilege *5-3, 5-7 
System configuration guidelines • 5-40 
to 5-48 

System management 
responsibilities* 1-20 
VAX PSI* 1-20, 5-5 
System service call* 1-30, 8-18, 8-19, 
8-32 

summary for nontransparent use* 
8-33, 8-43 

summary for transparent use *8-23, 
8-26 

System-level access control • 2-50 

T 


Tailoring the configuration database* 
5-10 

Target node *4-2 
Target task*8-14 
Target-initiated downline load *4-2 
Task 

declaring for network *8-10 
definition* 1-29 
downline load *4-22 
general purpose *4-25 
identifier in specification* 1-34 
source* 8-17 
specification* 1-33 
specification access control string • 
1-34 

specification for task* 1-34 
specification over the network* 1-34 
target *8-17, 8-28 
Task-to-task communication* 1-4, 

1-29, 8-1, 8-19, 8-32 
nontransparent • 8-9, 8-10, 8-32 
nontransparent MACRO example* 
8-64 

transparent • 8-1, 8-19 
transparent FORTRAN example* 
8-57 

transparent MACRO example *8-61 
TELL prefix 

description *3-9 


Terminal 

heterogeneous command *8-1 
Terminal connection 

to remote console *4-29 
Terminal emulator* 1-13, 2-19 
Terminal line 

conversion to DECnet line* 1-13, 
2-18, 5-1 1 
Terminal server 
LAT • A-13 
on Ethernet* 1-16 

Terminal, heterogeneous command* 
1-4, 1-29 

Tertiary loader*4-6, 4-14 
Test 

circuit loopback test *7-9, 7-13 
controller loopback test *7-11 
Ethernet loopback test *7-13 
local loopback test *7-8 
local-to-remote test • 7-5 
node-level test *7-2 
remote loopback test *7-3 
software loopback test *7-10 
X.25 test*7-17 
Testing the network *7-1 
Timer 

babble *3-61 
broadcast routing *3-95 
call *3-44 
clear* 3-44 
counter *3-36 
dead *3-81 
delay • 3-81 
hello *3-56 
inactivity *2-38, 3-99 
incoming • 2-38, 3-98 
line *3-80 
logical link *2-38 
outgoing • 2-38, 3-98 
recall • 3-68 
reset • 3-45 
restart* 3-46 
retransmit *3-81, 3-84 
routing • 2-37, 3-95 
scheduling • 3-81 
service *3-81 
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Timer (cont'd.) 
stream • 3-81 
transmit *3-61 
TLK image*4-22 
TMPMBX privilege*2-52, 5-3 
TO qualifier 

COPY KNOWN NODES command* 

3- 29 

Topology 

of a multiple-area network* 1-25 
of a single-area network* 1-25 
TOPS-10 node *9-23 
TOPS-20 node *9-27 
TQELM quota *5-43 
Tracing facility 
VAX PSI • 7-20 
Transmit password • 2-49 
Transmit timer *3-61 
Transparent 

communication* 1-33 
user network operations* 1-29 
Tributary* 1-10, 2-10 
address *2-10 
circuit timers *3-61 
control *3-58, 3-60 
TRIBUTARY parameter • 3-49 
TRIGGER command *4-2, 4-7 

PHYSICAL ADDRESS parameter* 

4- 8 

SERVICE PASSWORD parameter* 

4-10 

Trigger message *4-2 
Trigger operation 

bootstrap ROM • 4-4 
primary bootstrap • 4-4 
primary loader *4-2 
TRIGGER command *4-7 
TRIGGER VIA command *4-18 
TYPE parameter 

for executor node *3-87 
for GROUP *3-41 
for PVC • 3-65 


u 


UAF (user authorization file) *8-16 


UAF (user authorization file) (cont'd.) 
creation of default DECnet account* 

5-1 

UETP (User Environment Test Package) 
•5-8, 6-3 
UNA 

Ethernet circuit device *2-12 
Ethernet line device *2-23 
loopback test*7-13 
Unattended system 
memory dump *4-19 
slave *4-19 
UNIBUS 

devices* 5-47 
map registers*5-48 
Upline memory dump 
definition *4-19 
over Ethernet *4-20 
procedures *4-19 
requirements • 4-21 
RSX-11S system *4-19 
USAGE parameter 
for DLM circuit *3-69 
for PVC *3-65 
User 

interface to network* 1-28 
network operations*8-1 
transparent network operations* 
1-29 

User Environment Test Package 
See UETP 
User group 

See BCUG, CUG, and X.25 
User-defined object • 2-38 
USING qualifier 

COPY KNOWN NODES command* 
3-29 


v 


VAX Packetnet System Interface 
See VAX PSI 
VAX PSI* 1-3, 6-2 

bringing up a DTE *6-3 
command procedure for object* 
2-43 
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VAX PSI (cont'd.) 

configuration* 1-6, 1-25, 5-1, 5-36 
connector node *6-3 
database* 1-22, 3-4 
dumping KMS-11 microcode* 7-1, 
7-20 

line-level loopback test *7-1, 7-17 
multihost installation *6-3 
multihost mode* 1-4, 1-20, 5-1 
native mode* 1-3, 1-20 
native user programs *2-7 
object *2-43, 3-104 
software* 1-22, 2-1 
system management* 1-20, 5-5 
test facilities* 7-1 
tracing* 7-1, 7-20 
users* 1-20 

VAX PSI Access software* 1-18, 2-2, 
2-6, 2-46, 5-1 

VAX/VMS to IAS network operation* 
9-3 

VAX/VMS to P/OS network operation 
•9-6 

VAX/VMS to RSTS/E network 
operation *9-8 

VAX/VMS to RSX (using FCS-based 
FAL) network operation • 9-15 

VAX/VMS to RSX (using RMS-based 
FAL) network operation • 9-12 

VAX/VMS to RT-11 network 
operation *9-18 

VAX/VMS to TOPS-10 network 
operation • 9-23 

VAX/VMS to TOPS-20 network 
operation • 9-27 

VAX/VMS to VAX/VMS (previous 
DECnet release) network operation 
• 9-32 

VAXcluster 

configuration *1-14 

end node* 1-16, 2-33 

router* 1-16, 2-33 

use of Cl data link* 1-14 

use of DECnet-VAX data link* 1-14 

VAX/VMS 

network interface* 1-3 


VAX/VMS (cont'd.) 
node* 2-1 

nonpaged dynamic memory pool* 
5-40 

VERIFICATION INBOUND parameter* 
3-58, 3-119 

VERIFICATION parameter • 3-57 
Virtual circuit* 1-8, 1-11 

See also X.25 virtual circuit 
Virtual terminal* 1-13, 2-21 
enabling* 5-14 
VMR*4-23 

Volatile database* 1-22, 3-3 
copying node entries *3-29 
display information *3-125 
use of *3-3 


w 


Wildcard character 
for events *3-116 
Window size parameter • 3-43 
WITH qualifier 

COPY KNOWN NODES command* 
3-29 


x 


X.25 • 1-3, 2-5 

access module* 1-25, 2-6, 2-46 
access module commands *3-111 
BCUG • 2-6, 3-40, 3-107 
call destination *2-44 
CCITT recommendation • 1-3, 1-17 
circuit *2-7, 3-51 
circuit devices *2-13 
circuit identification *3-50 
circuit parameters *3-65 
connector node* 1-2, 1-4, 1-6, 1- 
18, 1-25, 2-2, 2-6, 2-43, 2-46, 
3-109, 3-111, 5-1, 6-3 
connector node configuration • 5-36 
CUG • 2-6, 3-40, 3-107 
data packet control • 3-42, 3-66 
gateway node* 1-4, 5-1 
handling incoming calls *3-105 
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X.25 (cont'd.) 

host node* 1-4, 1-18, 1-25, 2-2, 

2- 6, 2-43, 2-46, 3-109, 3-111, 
5-1 

host node configuration*5-36 
LAPB line protocol *3-74 
line*2-13, 2-15, 3-75 
line device*2-24 
line parameters • 3-84 
line receive buffers *3-86 
line-level loopback test *7-17 
multihost installation *6-3 
multihost mode* 1-18, 2-6, 5-1 
multihost mode network 
configuration • 5-35 
native mode* 1-18 
native-mode network configuration • 
5-33 

network-specific parameters • 3-42 
protocol module* 1-25, 2-2, 2-5, 

3- 37 

PSDN • 1-2 

PVC • 2-8, 2-14, 3-50 
server module* 1-25, 2-5, 2-6, 2-43 
server module commands*3-105 
SVC *2-8, 2-14, 3-50 
trace analyzer* 7-20 
trace module* 1-25 
user group *2-6, 3-40, 3-107 
virtual circuit* 1-2, 1-3, 1-17, 2-7, 
2-14 

X.25 Trace Analyzer 
See PSIXTA 
X.29 

CCITT recommendation* 1-3, 1-17 
incoming calls *3-108 
server module* 1-25, 2-5, 2-43 
server module commands*3-105 
terminal* 1-17 
X25-PROTOCOL module 
commands *3-37 
counters* 3-47 
parameters *3-37 
X25-SERVER module 
identification *3-105 
parameters *3-105 


X29-SERVER module 

See X25-SERVER module 


Z 


ZERO CIRCUITS command *3-71 
ZERO EXECUTOR command *3-37 
ZERO LINE command *3-87 
ZERO NODE command *3-37 
Zero-numbered object *2-39 
Zeroing 

line counters *3-87 
node counters *3-37 
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READER'S 

COMMENTS 


Note: This form is for document comments only. 

DIGITAL will use comments submitted on this form at the 
company's discretion. If you require a written reply and are 
eligible to receive one under Software Performance Report 
(SPR) service, submit your comments on an SPR form. 


Did you find this manual understandable, usable, and well organized? Please make 
suggestions for improvement. 


Did you find errors in this manual? If so, specify the error and the page number. 


Please indicate the type of user/reader that you most nearly represent: 

□ Assembly language programmer 

□ Higher-level language programmer 

□ Occasional programmer (experienced) 

□ User with little programming experience 

□ Student programmer 

□ Other (please specify) _ 


Name _Date_ 

Organization _ 

Street _ 

City _State_Zip Code . 

or Country 
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